執行乙個任務可能需要花費幾秒鐘，你可能會擔心如果乙個消費者在執行任務過程中掛掉了。一旦rabbitmq將訊息分發給了消費者，就會從記憶體中刪除。在這種情況下，如果正在執行任務的消費者宕機，會丟失正在處理的訊息和分發給這個消費者但尚未處理的訊息。
但是，我們不想丟失任何任務，如果有乙個消費者掛掉了，那麼我們應該將分發給它的任務交付給另乙個消費者去處理。
為了確保訊息不會丟失，rabbitmq支援訊息應答。消費者傳送乙個訊息應答，告訴rabbitmq這個訊息已經接收並且處理完畢了。rabbitmq就可以刪除它了。
如果乙個消費者掛掉卻沒有傳送應答，rabbitmq會理解為這個訊息沒有處理完全，然後交給另乙個消費者去重新處理。這樣，你就可以確認即使消費者偶爾掛掉也不會丟失任何訊息了。
沒有任何訊息超時限制；只有當消費者掛掉時，rabbitmq才會重新投遞。即使處理一條訊息會花費很長的時間。
訊息應答是
預設開啟
的。我們通過顯示的設定autoask=true關閉這種機制
。現即自動應答開，一旦我們完成任務，消費者會自動傳送應答。
通知rabbitmq
訊息已被處理，可以從記憶體刪除。如果消費者因宕機或鏈結失敗等原因沒有傳送
ack（不同於
activemq
，在rabbitmq
裡，訊息沒有過期的概念），則
rabbitmq
會將訊息重新傳送給其他監聽在佇列的下乙個消費者。
**示例：
生產者端**不變，消費者端**這部分就是用於開啟手動應答模式的。
// 監聽佇列，手動返回完成
channel.basicconsume(queue_name, false, consumer);
注：第二個引數值為false代表關閉rabbitmq的自動應答機制，改為手動應答。
在處理完訊息時，返回應答狀態。
// 返回確認狀態
channel.basicack(delivery.getenvelope().getdeliverytag(), false);
在處理完訊息時，返回應答狀態。
RabbitMQ訊息佇列 ACK機制
如果乙個consumer異常退出了，它處理的資料能夠被另外的consumer處理，這樣資料在這種情況下就不會丟失了 注意是這種情況下 為了保證資料不被丟失，rabbitmq支援訊息確認機制，即acknowledgments。為了保證資料能被正確處理而不僅僅是被consumer收到，那麼我們不能採用n...
RabbitMQ訊息佇列 ACK機制
如果乙個consumer異常退出了，它處理的資料能夠被另外的consumer處理，這樣資料在這種情況下就不會丟失了 注意是這種情況下 為了保證資料不被丟失，rabbitmq支援訊息確認機制，即acknowledgments。為了保證資料能被正確處理而不僅僅是被consumer收到，那麼我們不能採用n...
RabbitMQ訊息佇列 ACK機制
每個consumer可能需要一段時間才能處理完收到的資料。如果在這個過程中，consumer出錯了，異常退出了，而資料還沒有處理完成，那麼 非常不幸，這段資料就丟失了。如果乙個consumer異常退出了，它處理的資料能夠被另外的consumer處理，這樣資料在這種情況下就不會丟失了 注意是這種情況下...