rabbitMQのAckまたはNack
私はrabbitMQを使用しています。basic_getを使用してキューからすべてのメッセージを取得し、自動的に確認応答を行いません。つまり、メッセージを確認または確認するまでメッセージはキューに残ります。
例外がスローされたために処理できないメッセージが表示され、完全に処理できなかった。
質問は、成功したメッセージとスローされた例外の両方を確認する場合、何が問題になるかです。つまり、結果メッセージは常にキューから取得されるため、このシナリオでackまたはnackを使用する場合はどうなりますか？多分私は各oprationを使用するときに何かを逃しますか？
basic.nack コマンドは明らかにRabbitMQの拡張機能で、 basic.reject の機能を拡張して一括処理モードを含めます。どちらにもrequeueの「ビット」（つまりブール値）フラグが含まれているため、実際にはいくつかの選択肢があります。
nack/rejectwithrequeue=1：メッセージは、新しいメッセージであるかのように、元のキューに返されます。これは、消費者側で一時的な障害が発生した場合に役立ちます。nack/rejectwithrequeue=0と構成済みのデッドレターエクスチェンジ（DLX）は、メッセージをそのエクスチェンジにパブリッシュし、別のキューでピックアップできるようにします。nack/rejectwithrequeue=0そしてDLXはメッセージを単に破棄しませんackは、DLXが構成されている場合でも、キューからメッセージを削除します
DLXが設定されていない場合、常にackを使用すると、nack/rejectとrequeue=0;ただし、最初から論理的に正しい関数を使用すると、後で別の方法で構成する際の柔軟性が高まります。
AckとNackはどちらもキューからメッセージを削除しますが、メッセージにNackを実行すると、そのキューにメッセージが定義されている場合、メッセージがDLX（デッドレターキュー）に入る点が異なります。