私たちは耐久性のあるRabbitMQキューを持っています。コンシューマがキューからアイテムを取得すると、コンシューマはそのアイテムを処理し、それを認識します。消費者がアイテムを処理できなかった場合は、誰かが問題を解決するのを待ってエラーを表示して停止します。確認応答は送信されません。消費者が受信したアイテムを再起動すると、キュー内の次のアイテムになります。 Basic.Recover（）は役に立ちません（.NETクライアントを使用）。 キューとして機能させる方法を考えてください - それがアックされていなければ、常に最初のアイテムを取得します。RabbitMQベーシックリカバリが動作しない
this entry in the RabbitMQ FAQを参照してください。あなたはRabbitMQのは、すぐに戻って（あなたの消費者がそれらをプルダウンする前に彼らがいた）キューの先頭にあなたのunackedメッセージを再キューイングする場合がありますが、現実はそうあなたが経験してきたように、異なるものになるだろう。
は、だから、Basic.Recover()が、それはあなたが期待されるように動作していないだけという（は、将来の再処理のためにキューに戻されたメッセージを）動作しないということではありません。
私の頭の中の何かが、の場合、プリフェッチ回数を1に設定し、いつでも1つのコンシューマだけがキューに接続することで、そのような場合は保証できません。それは試してみる価値がある。しかし、たとえそれが動作しても、ケースを永遠にとどめることに頼るものではなく、そのようなプリフェッチカウントが低いと、消費者のメッセージ/秒のパフォーマンスにおそらく苦しんでしまうでしょう。
メッセージは、2つの方法で消費することができるNOACK = FALSEまたはNOACK =真
ノアックがノアクが真メッセージに設定されている
が自動的に削除されModel.BasicConsumeとModel.BasicGet
両方でパラメータであります配信後のキューnoAskがfalseに設定されている場合、basicAckを呼び出すとメッセージが削除されます。noAck = falseで、basicAckを呼び出さないと、メッセージは残りますが、アプリケーションを再起動するか、最初にそれを消費した接続を閉じるまで、他のコンシューマーでは受信されません。 BasicRejectを呼び出すと、メッセージはサブスクライバに再配信されます。
こちらがお役に立てば幸いです。
あなたはおそらく代わりに「ノアック」に上記のあなたの多くの「noAsk」の例を変更する必要があります。 –
この動作は、1つの優先度が高い優先度と通常の優先度の2つのキューを持つことで実現できます。プリフェッチカウントを1に設定し、basic.getを使用してキューを交互に切り替えます。ほとんどの場合、プライオリティキューは空ですが、再キューイングしたいときは、プライオリティキューにメッセージを再度パブリッシュしてください。
これは、あなたがメッセージストリームを消費する複数のプロセスを持っているシナリオで動作し、1つのプロセスメッセージに救済することを決定します。そのメッセージはすぐに別のプロセスによって取得されます。
私のシナリオは非常に簡単です。消費者は1人で、メッセージの順序は重要です。予期しないシャットダウン（停電）が発生した場合、RabbitMQはキューの最初のメッセージをキューの最後に置きます。だから私は、クライアントがデキューするまで、まず最初にメッセージを残すために、他のブローカーを使うべきだと思う。 – Kimi
私はここでより関連性の高い質問をしました。http://stackoverflow.com/questions/6369190/what-open-source-message-queuing-software-provides-durability-with-strict-orderin – Kimi
RabbitMQのは今のメッセージが掲載順にキューに再登録されるように、この問題since 2.7.0の一部を固定しているようです。キューに複数のサブスクライバがある場合でも、元の順序からメッセージが到着する可能性があります。
私の計画は、プリフェッチカウントを1に設定し、失敗したメッセージをファイルにシリアル化して、とにかくそれを確認することです。プロセスが再び開始すると、そのファイルから最初のメッセージが取得され、処理された後、キューの消費が再開されます。 – Kimi
これは、プロセスを強制終了した場合には動作しません。ウサギはとにかくキューの終わりにそれを置くでしょう。 – Kimi