今日、この質問を受けましたが、その答えはチーム内で意見が分かれているようです。
シナリオ 特定のトピックに関するイベント (メッセージ) を (EasyNetQ 経由で) RabbitMQ に送信する複数のパブリッシャーがいます。彼らはFIFOを保証すると言いました。彼らは、「トピック」のメッセージを順番に「処理」することを保証するシステムを構築したいと考えています。
私の解決策 トピックごとに「バージョン番号」を保持するキャッシュを用意し、シーケンスが一致しなかった場合はメッセージの処理を保留します。最初のイベント処理が完了し、キャッシュが新しいターゲット バージョンに更新された後、メッセージの処理を再試行できます (時間遅延再試行)。これは、コンシューマーが基本的に別のコンシューマーが処理を完了するのを待っていることを意味します。これは、一種のロックであるため、数秒ではなく数ミリ秒かかるものに対して機能します。
あるいは、このhttp://blog.jonathanoliver.com/cqrs-out-of-sequence-messages-and-read-models/のように、順不同のイベントの保持テーブルを実装できると言いました
問題を提起した人は、それらの答えは両方とも間違っていると言いました.
彼らが言った解決策は、ルーティングキーと直接交換を使用し、トピックを常に同じコンシューマーに送ることでした。スティッキー負荷分散システムのようなものです。任意の時点でのコンシューマーの数に応じて交換/バインディングを更新する必要があるため、これによりシステムのオンデマンドのスケーラビリティが制限されることを指摘しました。
以前にこのパターンを実装したことがある人の意見を聞きたいです。ここには正しい解決策と間違った解決策がありますか?それとも、処理の遅延やスケーラビリティなどに基づいて正しい戦略を選択するケースですか?
編集：明確にするために。どのソリューションが自分の状況により適しているかを判断するために、各アプローチの長所と短所を見つけることを期待しています。落とし穴などはありますか？