4

ZMQ を使用してパブ/サブ アーキテクチャを設計しています。私は最大限の信頼性とスケーラビリティを必要としており、与えられた可能性の地獄に迷い込んでいます。

現時点では、ブローカーによってリンクされたパブリッシャーとサブスクライバーのセットを取得しています。ブローカーは、パブリッシャーのフロントエンドとサブスクライバーのバックエンドを公開するシンプルなフォワーダー デバイスです。

ブローカーがクラッシュまたは切断した場合に対処し、全体的なスケーラビリティを改善する必要があります。

そこで、複数のブローカーを追加することを考えました。パブリッシャーはブローカーをラウンドロビンしてメッセージを送信し、サブスクライバーはこれらすべてのブローカーをサブスクライブするだけです。

次に、可能なブローカーのリストを取得する方法が必要だったので、必要に応じてブローカーのリストを提供するネーム サービスを作成しました。パブリッシャーとサブスクライバーは、このサービスに接続するブローカーを尋ねます。

また、メインのネーム サービスが機能しなくなった場合に備えて、一種の「怠惰な海賊」 (つまり、次々に試行/再試行) の信頼できるネーム サービスも作成しました。

コードベースのサイズと複雑さが止まらないため、設計が間違っていると思い始めています。ZMQ が提供する可能性のジャングルで迷っています。

たぶん、ルーター/ディーラーベースの何かがここで使用できるでしょうか?

どんなアドバイスでも大歓迎です！

4

2 に答える 2

7

非常に多くの仮定に基づいているため、質問に直接答えることはできません。その多くはおそらく間違っています。

間違ったアプローチを使用しているため、迷子になっています。0MQ を、まだよく知らない言語と考えてください。「最大限の信頼性とスケーラビリティ」を書き始めると、ゴジラの吐き気になってしまいます。

だから：私がガイドで使用するアプローチを使用してください。コア メッセージ フローに対する最小限のソリューションから始めて、適切に機能するようにします。使用するソケットの種類を慎重に検討してください。次に、完全にテストするたびに、実際に何が起こっているのかを確実に理解できるように、段階的な改善を行います。コードの成長に合わせて、定期的にコードをリファクタリングします。安定した最小バージョン 1 ができるまで続けます。最初から「最大」を目指してはいけません。

最後に、問題をよりよく理解したら、最初からやり直して、いくつかの手順で作業モデルを構築します。

問題を完全に支配し、それを解決する最善の方法を学ぶまで繰り返します。

于 2011-12-06T13:07:09.767 に答える
4

複雑さのほとんどは、障害が発生した場合にブローカー サービスを存続させようとすることに起因しているようです。これをアプリケーション レベルで解決すると、最高度の柔軟性が得られますが、ゼロから始める場合は最も多くの労力が必要になります。

これをアプリケーション レベルで処理する代わりに、ネットワーク レベルで処理することもできます。ブローカーを他の単純なネットワーク サービスと同じように扱い、IP フェイルオーバー メカニズム (例: Pacemaker/corosync、UCARP など) を使用して、プライマリ サービスが利用できなくなった場合に仮想 IP アドレスをセカンダリ サービスにフェイルオーバーします。

これにより、ネーム サービスが不要になるため、パブリッシャーとサブスクライバーが大幅に簡素化されます。単一の仮想 IP アドレスについて知る必要があるだけです。ZMQ は、必要に応じて (つまり、フェイルオーバーが発生した場合)、サービスへの再接続を処理します。

于 2011-12-06T02:17:50.457 に答える