7

ZeroMQ を理解し、試し始めたところです。

各コンポーネントが MQ で読み取りと書き込みの両方を行えるように、2 つ以上のアクター (パブリッシャーとサブスクライバー) 間で双方向通信を行う方法が明確ではありません。

これにより、各コンポーネントがイベントをリッスンし、別のイベントで応答できるため、イベント駆動型アーキテクチャを作成できます。

ZeroMQ で直接これを行う方法はありますか、それとも独自のソリューションをその上に実装する必要がありますか?

4

1 に答える 1

10

単純な双方向通信が必要な場合は、各ノードにパブリッシング ソケットをセットアップし、それぞれを他のノードに接続させます。

多対多のセットアップでは、これはすぐに扱いにくくなります。基本的には、すべてのノードが「接続」してメッセージを受信し、サブスクライバーの条件が満たされた場合にメッセージを送信できる、ある種の中央ノードが必要なようです。

ZeroMq は単純な「電源ソケット」であり、メッセージ キューではないため (ZeroMQ - ゼロ メッセージ キューという名前が付けられています)、すぐに使用できるわけではありません。

簡単な代替手段は、各ノードに UDP ブロードキャスト ソケットを設定させることです (ZeroMq を使用せず、通常のソケットのみを使用します)。すべてのノードは、発生したことをリッスンし、独自のメッセージをソケットに「パブリッシュ」して、リッスンしている任意のノードに効果的に送信できます。この設定は、LAN 上で、メッセージが失われても問題ない設定 (定期的な状態の更新など) で機能します。メッセージの信頼性 (および場合によっては耐久性) が必要な場合は、より高度な本格的なメッセージ キューが必要です。

永続的なメッセージ キューを使用せずに済む場合は、すべてのノードがサブスクライブしてデータを送信できるセントラル ノード (セントラル メッセージ ハンドラー) に基づくソリューションを作成できます。基本的に、1 つの REP (応答) ソケット (受信データ用) と 1 つの PUB (Publisher) ソケット (送信データ用) を備えた「サーバー」を作成します。次に、各クライアントは REQ (要求) ソケットを介してサーバーの REP ソケットにデータを発行し、サーバーの PUB ソケットに SUB (サブスクライバー) ソケットを設定します。

利用可能なさまざまなメッセージ パターンに関する ZeroMq ガイドを確認してください。

少しスパイスを加えるために、(サーバーの PUB ソケットで) 発信メッセージを 2 つのメッセージ部分 (マルチパート メッセージを参照) に分割することにより、サーバー側のフィルタリングを含むイベント「トピック」を追加できます。 "topic" で、2 番目の部分にはペイロードが含まれます (例: temp|46.2speed|134 )。このようにして、各クライアントは任意のトピック (またはすべて) への関心を登録し、サーバーが一致するメッセージのみをフィルター処理できるようにします。詳細については、この例を参照してください。

基本的に、ZeroMq は通常のソケットの「単なる」抽象化であり、その上にソリューションを構築するためのいくつかのメッセージング パターンを提供します。ただし、多くの面倒な作業から解放され、通常とは異なるスケーラビリティとパフォーマンスが提供されます。ただし、慣れが必要です。詳細については、ZeroMq ガイドをご覧ください。

于 2013-02-05T18:55:57.500 に答える