RabbitMQ を介したジョブ キューのようなものがあります。ジョブをキャンセルするリクエストがあった場合、まだ処理を開始していないタスク (メッセージが確認されていない) を取り消したいと考えています。これは取り消しに対応します。ルーティングされたキューからのこれらのメッセージ。
AMQP または RabbitMQ API でこの機能を見つけられませんでした。おそらく私は十分に検索していませんか?または、回避策を使用する必要がありますか (難しいことではありませんが)。
RabbitMQ を介したジョブ キューのようなものがあります。ジョブをキャンセルするリクエストがあった場合、まだ処理を開始していないタスク (メッセージが確認されていない) を取り消したいと考えています。これは取り消しに対応します。ルーティングされたキューからのこれらのメッセージ。
AMQP または RabbitMQ API でこの機能を見つけられませんでした。おそらく私は十分に検索していませんか?または、回避策を使用する必要がありますか (難しいことではありませんが)。
このシナリオを解決するには、ワーカーに何らかの信頼できるデータ ソースをチェックして、ジョブを続行するかどうかを判断させます。たとえば、ワーカーはデータベース内のジョブのステータスをチェックして、ジョブが既にキャンセルされているかどうかを確認します。
ジョブの処理速度が、権限のあるストアの更新と読み取りの速度よりも速い可能性があるシナリオでは、他の特性と引き換えに速度を犠牲にする保証の少ないデータ ストアが役立つ場合があります。
この例は、MySQL のようなリレーショナル DB の代わりに、Redis をメッセージの処理をキャンセルするためのストアとして使用することです。Redis は非常に高速ですが、保持するデータに関する保証は少なくなります。一方、MySQL は非常に低速ですが、保持するデータに関する保証は多くなります。
最後に、メッセージを処理するかどうかを別のソースで確認するという概念は同じですが、それを実装する方法は特定のシナリオによって異なります。
RabbitMQ では、エンキューされたメッセージを変更または削除することはできません。そのためには、ある種のデータベースで各ジョブの状態を保持し、 RabbitMQ を使用して関係者にその状態の変化を通知する必要があります。
ボリュームが少ない場合は、ジョブごとにキューと一緒にまとめることができます. キューを作成し、ジョブの説明をキューに投稿し、キューの名前をワーカーに通知します。ジョブを処理する前にキャンセルする必要がある場合は、ジョブのキューを削除します。ワーカーがジョブの説明を取りに来ると、キューがなくなったことに気付くでしょう。
軽量で一般的には、redis または別のキー/値ストアを使用してジョブの状態を保持し (削除されたまたは存在しないレコードは、キャンセルされたまたは存在しないジョブを意味します)、rabbitmq を使用して、キー内の新規/削除/変更されたレコードについて通知することをお勧めします。 /値ストア。
目標を達成するには、少なくとも 2 つの方法があります。
basic.reject
が設定されている場合、メッセージを再キューイングしますrequeue=true
(そうでない場合、メッセージは拒否されます)。
(RabbitMQ 2.0.0 以降でサポートされています。http: //www.rabbitmq.com/blog/2010/08/03/well-ill-let-you-go-basicreject-in-rabbitmq/ を参照してください)。
basic.recover
チャネルで未確認のメッセージを再配信するようブローカーに依頼します。
メッセージがルーティングされたすべてのキューにサブスクライブし、それらを ack で消費する必要があります。
たとえば、ルーティング キーとして「test」を使用してトピック エクスチェンジにパブリッシュし、「test」をサブスクライブする 3 つの永続キューがある場合、これら 3 つのキューを消費する必要があります。コンシューマー プロセスもリッスンする別のキューを追加し、それらのメッセージを無視するように指示する方がよい場合があります。
別の方法として、RabbitMQ を使用しているため、すべてのキューをクリアする帯域外命令を受け入れるカスタム交換プラグインを作成することもできます。たとえば、このメッセージの宛先であるすべてのキューをクリアするように指示する特別なメッセージ ヘッダーを交換機に読み取らせることができます。これには Erlang コードを書く必要がありますが、4 つの異なる交換タイプが実装されているため、最も類似したものをコピーして、新しい動作のコードを書くだけで済みます。これにカスタム ヘッダーのみを使用する場合、メッセージの本文はコンシューマー向けの通常のメッセージにすることができます。
総括する:
1) パブリッシャーはメッセージ自体を消費する必要がある 2) パブリッシャーは特別なメッセージを特別なキューで送信して、コンシューマーにメッセージを無視するように伝えることができる 3) パブリッシャーは特別なメッセージをカスタム交換に送信し、そこから既存のメッセージを消去することができるこの特別なメッセージを消費者に送信する前にキューに入れます。