メディエータのないZeroMQ Pub-Sub + Dynamic Discovery

Question

私は、中規模システムの場合、ZeroMQをPub-Sub（サービスバススタイル）インフラとしてテストしています。 私たちは約50のノードを持っています。それらはすべてパブリッシャーとサブスクライバーでなければなりません。 ネットワークはスタートポロジのようなものですが、エッジはお互いに「話し合っています」。 ダイナミックディスカバリ（参加者のネットワークアドレスをハードコードする必要はありません）が必要ですが、SPOF（Single Point of Failure）も必要ありません。

http://zeromq.org/whitepapers:0mq-3-0-pubsubと私が理解しているところからは、動的ディスカバリのために提案されている0MQの方法は、サブスクリプションとパブリケーションを転送するプロキシノード（XPUB/XSUB）を必要とします。 （A）プロキシノードがSPOFである - システム全体が機能していないときにエラーが発生する （B）このシステムでは、このようなプロキシを中央メディエータとして使用することを検討しましたが、データを含むすべてのトラフィックは、プロキシノードを通過します。これは、待ち時間&のパフォーマンスの問題を意味します。

私がpub-subホワイトペーパーを正しく理解していると仮定すると、ZeroMQでpub-sub + dynamic-discovery + no-SPOFを達成するための比較的簡単な方法がありますか？

追加ポイント：ほとんどのメッセージには利害関係者が1人または少数しかいないため、ネットワークを混雑させたくないため、マルチキャスト（PGM）ソリューションを除外しました。

Answer 1

1つのパブリッシャを持つ複数のサブスクライバは、サブスクライバがパブリッシャに直接話すことができるため、仲介を必要としません。しかし、同時に多くの出版社と購読者はそれほど簡単ではありません。真ん中に何かがある場合を除き、新しい加入者が既存のすべての出版社で構成されなければならないため、メンテナンスは悪夢となります。

複数のXSUB/XPUBプロキシをそれぞれ独自のマシンに展開し、パブリッシャとプロキシの間にロードバランサ（F5など）を配置することができます。これにより、上流側で負荷分散とフォールトトレランスが実現されます。

プロキシコードは単純です：プロキシノードに障害が発生した

Socket frontend = context.socket(ZMQ.XSUB); 
frontend.bind("tcp://proxy1:5444"); 
Socket backend = context.socket(ZMQ.XPUB); 
backend.bind("tcp://proxy1:5555"); 
frontend.subscribe("".getBytes()); 
ZMQ.proxy (frontend, backend, null); 

場合は、それを再起動します。再接続/サブスクリプションはzmqによって自動的に処理されます。下流の加入者のための

、利用可能なすべてのプロキシに直接各加入者を接続する：

subscriber = ctx.createSocket(ZMQ.SUB) 
subscriber.connect("tcp://proxy1:5555") 
subscriber.connect("tcp://proxy2:5555") 
subscriber.connect("tcp://proxy3:5555") 

来るので、プロキシの数ので、少ない構成のメンテナンスにプロキシ結果に直接加入者を結ぶ、プロキシよりも頻繁に行きます

出版ほとんどの場合、静的になります。

プロキシノードに障害が発生した場合、アップストリームLTMは残りのプロキシノードに応じてトラフィックをルーティングします。利用可能なすべてのプロキシから消費されるため、加入者は影響を受けません。

遅いサブスクライバは、同期で対処することができます。thisを読んでください。
サブスクリプション・フォーワードとネットワーク・トラフィックを最小化するhereをチェックしてください。