ZMQパブ/サブ信頼性/スケーラブルデザイン

Question

私はZMQを使ってパブ/サブアーキテクチャを設計しています。最大限の信頼性とスケーラビリティが必要であり、提供される可能性が失われてしまいます。

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

ブローカがクラッシュしたり切断されたりすると、ケースを処理してスケーラビリティを向上させる必要があります。

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

私は可能なブローカーのリストを取得する方法が必要でしたので、私は要求に応じてブローカーのリストを提供するネームサービスを書きました。パブリッシャーとサブスクライバーは、どのブローカーに接続するかをこのサービスに依頼します。

また、メインネームサービスが壊れた場合に、一種の信頼できるネームサービスを「怠惰な海賊」と書きました。

コードベースがサイズや複雑さが増していないので、間違っていると思っています。私はZMQによって提供される可能性のジャングルで迷っています。

ルータ/ディーラーベースのものはここで使用できますか？

アドバイスをいただければ幸いです！

Answer 1

あなたの質問に直接答えることはできません。多くの場合、おそらく間違っていることを前提としています。

あなたが間違ったアプローチを使用しているため、あなたは迷子になります。 0MQは言語として考えてください。あなたはそれほどよく知らない言語です。 「最大の信頼性とスケーラビリティ」を書こうとすることから始めれば、ゴジラの吐き気に終わるでしょう。

したがって、ガイドで使用している方法を使用してください。コアメッセージフローの最小限のソリューションから始めて、適切に動作させるようにしてください。使用するソケットの種類については非常に注意深く考えてください。その後、実際に何が起こっているかを理解するために、テストを行うたびに段階的な改善を行います。コードを定期的にリファクタリングしてください。安定した最小限のバージョン1が完成するまで続けます。開始時に何か「最大」を目指さないでください。

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

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

Answer 2

ほとんどの複雑さは、障害発生時にブローカサービスを継続しようとしているようです。これをアプリケーションレベルで解決することで、最高の柔軟性を得ることができますが、最初から始めようとする場合は最大の労力が必要です。

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

名前サービスが不要なため、パブリッシャーとサブスクライバーが大幅に簡素化されます。彼らは単一の仮想IPアドレスについて知る必要があります。 ZMQは、必要に応じて（つまり、フェールオーバーが発生したとき）サービスに再接続します。