11

node.jsをjmsトピックへのクライアントとして使用しています。トピックで接続を確立するために使用できるプロトコルは2つあります。これらはStompとAMQPです。http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol およびhttp://en.wikipedia.org/wiki/Streaming_Text_Oriented_Messaging_Protocolでそれらについて簡単に読んでいます。どちらも有線レベルのプロトコル、つまりオクテットのストリームとしてネットワークを介して送信されるデータのようです。どちらを優先すべきか具体的な理由はわかりません。誰かがそれに光を当てることができれば、それは役に立ちます。

もう1つのポイントは、両方のプロトコルが相互運用可能であると述べることに誇りを持っていることです。相互運用可能な用語は、誰かが特定のメッセージブローカーの実装を削除してapache active MQを実行し、代わりにWebsphere MQをプラグインしたい場合、移行がスムーズになることを意味しますか（AMQP / STOMPまたはその他のワイヤーレベルプロトコルの両方をサポートしている場合）？

4

1 に答える 1

2

パフォーマンスに違いが見られる場合があります (メッセージ サイズやキュー エントリの持続性要件など、多くの要因に基づいて、このベンチマークを参照してください。

よくあることですが、特にメッセージのサイズ/カウントなどの場合は、考慮すべき他の要因もあります。パフォーマンスの点で明確な勝者が存在するという意味ではなく、機能要件を満たしているプロトコルとそうでないプロトコルはありません。

この記事は特に、さまざまな STOMP ブローカーの実装でより多くの断片化がある可能性があることを示唆しています。その記事から引用

STOMP...「宛先」文字列で SEND セマンティックを使用します。ブローカーは、トピック、キュー、交換など、内部で理解できるものにマップする必要があります。次に、消費者はそれらの宛先にサブスクライブします。これらの宛先は仕様で義務付けられていないため、さまざまなブローカーがさまざまなフレーバーの宛先をサポートしている可能性があります。そのため、ブローカー間でコードを移植するのは必ずしも簡単ではありません。

少なくとも AMQP (最も重要な利点の 1 つとして相互運用性を謳っている) では、プロバイダー/言語の切り替えで発生する唯一の問題は、前述の新しいプロバイダーのセットアップに固有のものです。たとえば、ZeroMQ は、RabbitMQ よりも多くの構成作業が必要になる可能性が高いと読みましたが、それは AMQP に固有の属性によるものではありません。

于 2013-06-17T18:06:17.963 に答える