一貫性のあるハッシュ交換でバインドされた期限切れキューのデッドレターメッセージ

Question

特定のソースに関連するイベントを処理している状況があります。各ソースにはキーまたはIDがあり、これをハッシュとして使用できます。各ソースからのイベントを順番に処理する必要がありますが、異なるソースからのイベントを並列化して水平スケーラビリティを実現できます。何百ものソースキーがあります。

メッセージをRabbitMQに送信するときに、ルーティングキーの一部としてキーを設定してから、consistent-hash-exchangeを使用して、同じソースのイベントが同じキューにルーティングされるようにする予定です。私は、消費者からプライベートキューを動的にバインドすることを考えていました。これは、TTLを使用することで（コンシューマがダウンした場合に正常に削除されるように）考えていました。最初は冗長性のために2〜3人の消費者しかいませんが、メッセージの数が増えたためにスケールアップしたい場合は、別のコンシューマーを始めることができます。

私の質問は、コンシューマがダウンしてキューにメッセージがあるとどうなりますか？理想的には、キュー内のメッセージをconsistent-hash-exchange（別のキューにルーティングする）（元のキューはもう存在しないため）に交換し直す必要があります。

RabbitMQのドキュメントdead letteringでは、コンシューマキューのTTLのシナリオ、またはキューが削除されたときの動作については明記されていません。

私のアプローチは意味がありますか？特定のルーティングキーによる注文を維持しながら、私が探しているコンシューマーフォールトトレランスを実現するにはどうすればよいですか？

注：デッドレターメッセージをExchangeにルーティングする過程で、もともと期限切れのキューにルーティングされていた新しいメッセージが、別のコンシューマにルーティングされる場合は、したがって、特定のインスタンスで順序が崩れます。

Answer 1

ここで答えられる質問が1つ多くありますが、私は同じ順序で進もうとします。

My question is what happens if a consumer is down and there are messages in its queue?
メッセージの外側（質問の残りの部分） - メッセージは、ACKが送信されるか、TTLの有効期限が切れるまでキューに残ります。

The RabbitMQ documentation about dead lettering doesn't explicitly mention the scenario of TTL on consumer queues, or what happens when the queue gets deleted.
それは、はは...The TTL for the message expires...を言うんので、メッセージが与えられたTTL以内にACKされていない場合は基本的に、それはDLXへのを取得します。キューTTLの場合、check this link - 基本的にキューの「有効期限」です。さらに、キューが削除された場合、メッセージは消えてしまいます（もちろん、ミラーリングを考慮していない場合）。

「それは意味をなさない」の部分になりました。さまざまな情報源からのメッセージについて、私はそれが明らかだと思います。あなたが並行してできるだけ多くのプロセスを行えばそれだけです。そこには衝突はありません。

How can I achieve the consumer fault-tolerance I am looking for while retaining the ordering by a specific routing key? 逐次処理の場合、基本的に1つのソースを持つコンシューマが1つだけ必要です。今、このコンシューマを監視するために、ウォッチドッグを追加してクラッシュした場合に再起動したり、ハングアップなどの場合に再起動したりすることがあります。consume（amqp）メソッドの代わりにgetを使用すると意味があります。 （私にとっては少なくとも）それは非常にユースケース固有のもの（パフォーマンス、新しいメッセージがある頻度など）が、この方法では推奨できないか、推奨できませんが、 "より同期的な"動作。

あなたが実際にシーケンスの元の順序を保持したい場合は、DLX-ingメッセージ（より高いTTLなど）を避けてください。 :)）