不必要な雑談を発生させずに水平方向にスケーリングする能力について、さまざまな pub/sub メッセージング プロトコルを評価しようとしています。
私のアーキテクチャには、Web ソケット クライアントが接続された NodeJS サーバーがあります。一貫性のあるハッシング ベースのルーターを使用して、クライアントがサブスクライブすることに関心のあるトピックに基づいて、クライアントをサーバーに誘導することを計画しています。これは、特定のトピックについて、サーバーのサブセットのみがそのトピックにサブスクライブするクライアントを持つことを意味します。その後、メッセージは pub/sub ブローカーにパブリッシュされます。pub/sub ブローカーは、そのデータをサブスクライバーを持つサーバーにファンアウトする役割を果たします。
私が避けたい状況は、すべてのブローカーがすべてのリクエストを受け取り、ネットワークが飽和状態になる状況です。これは、Redis Pub/Sub のスケーリングに関する明らかな問題です。サーバーを追加しても、n 個の正方形の問題が発生することはありません。
pub/sub プロトコル上のクライアントの数は、サーバーの数になります。理想的には、不要なネットワーク帯域幅を回避するために、各サーバーが複数の NodeJS プロセスにデータを効率的にファンアウトするローカル ブローカーを持つことができます。ほとんどの場合、特定のトピックについて、すべてのサブスクライバーが同じサーバー上に存在します。
この種のトピックベースのデータ伝播を提供する pub/sub プロトコルはどれですか?
私が評価しているプロトコルは、MQTT、RabbitMQ、ZMQ、nanomsg です。これは包括的ではなく、SAAS オプションは受け入れられます。
品質保証の制約は簡単です。多くても 1 回、または少なくとも 1 回で十分です。承認は重要ではありません。イベントの順序は重要ではありません。私たちは、水平方向のスケーラビリティに重点を置いて、ファイア アンド フォーゲットを探しています。