1

システムのデータが変更されると、すべての変更を少なくとも 4 つの異なるコンシューマー (1 秒あたり約 3000 メッセージ) に公開するので、メッセージ ブローカーを使用したいと考えています。
コンシューマのほとんどは、データベース テーブルを変更して更新する責任があります。

（DBは異なります-カウチ、mysqlなど、独自のレプリケーションメカニズムを使用したり、dbトリガーを使用したりするなどのソリューションは不可能です）質問

  1. メッセージブローカーを使用して DB 間でデータを複製した経験のある人はいますか?
    それは良い習慣ですか？

  2. 失敗した場合はどうすればよいですか？
    たとえば、RabbitMQ を使用して、クライアントがキューから 10,000 件のメッセージを削除し、ACK を送信し、それらを処理する前に毎回例外をスローしたとします。今、それらは失われています。キューに戻る方法はありますか?

    (それらを再キューイングすると、順序が台無しになります)。

  3. rabbitMQ を使用することは良い習慣ですか? Kafka のようにキューに戻る機能は、シナリオを失敗させるために重要ではありませんか?

ありがとう。

4

1 に答える 1

0

私はメッセージ ブローカーを使用した DB レプリケーションの経験はありませんが、これが正しい方向に進むのに役立つかもしれません。

2. 失敗した場合はどうすればよいですか?

たとえば、RabbitMQ を使用して、クライアントがキューから 10,000 件のメッセージを削除し、ACK を送信し、それらを処理する前に毎回例外をスローしたとします。今、それらは失われています。キューに戻る方法はありますか?

デッド レタリングを使用して、メッセージが失われないようにすることができます。長時間実行されるタスクでない限り、消費者がそれらを正常に処理したことを確認するまで、承認しないことをお勧めします。失敗した場合は、配信不能キューに送信する代わりに。スループットは中程度なので、注意が必要です。basic.rejectbasic.ack

ただし、順序は保証されません。発行された順序でそれらを回復するための手動メカニズムを実装する必要があります。おそらく、ある種のタイムスタンプまたは ID メカニズムを備えたメッセージ ヘッダーを使用して、正しい順序で再処理します。

于 2014-02-12T15:16:46.050 に答える