rabbitmq的消費確認機制主要分為三個類型：
1.none
2.自動auto（默認）
3.手動manual
在配置文件中通過以下進行配置
spring.rabbitmq.listener.simple.acknowledge-mode=auto
spring.rabbitmq.listener.simple.acknowledge-mode= none
spring.rabbitmq.listener.simple.acknowledge-mode = manual
AUTO
rabbitmq默認的確認方式為auto,即自動確認，即消費者消費消費消息后會自動給broker發(fā)送確認信息蛾派，但在消費過程中發(fā)生異常的話豪椿，要分以下情況：
1.拋出AmqpRejectAndDontRequeueException異常時根时，消息會被拒絕示括，且不會回到消息隊列
2.拋出ImmediateAcknowledgeAmqpException異常會被消費確認。
3.拋出其他異常声邦，消息會重新回到隊列编丘，重新推送給消費者，一直到消費成功谱煤，否則會一直循環(huán)摊求，所以在消費自動確認模式下，需要配置消息重試機制刘离，合理處理發(fā)生異常重試的消息室叉。
Manual
手動確認的模式下，在消費端需要手動向broker發(fā)生消息確認寥闪，broker會根據(jù)返回的ack刪除該已消費的消息 太惠。但是如果發(fā)送異常且沒有手動處理并進行消息確認、拒絕疲憋、失敗的操作凿渊，即broker沒有收到任何的ack信息，消息隊列仍然會保留該消息缚柳，并在后續(xù)進行重新投遞埃脏，直到該消息被確認或拒絕。所以在開發(fā)中應該妥善處理異常情況秋忙，并搭配重試機制彩掐，死信隊列。手動模式下灰追，確認方式有以下3種：
1.basicAck
basicAck(long deliveryTag, boolean multiple)堵幽，表示成功確認，broker會刪除該消息弹澎，參數(shù)deliveryTag表示消息的唯一序號朴下，multiple表示是否一次消費多條消息，false表示只確認該序號對應的消息苦蒿，true表示確認所有比此序號小的消息殴胧。
2.basicNack
basicNack(long deliveryTag, boolean multiple, boolean requeue)，表示失敗確認，一般在消費異常的時候用到团滥，參數(shù)requeue表示是否重新入隊列竿屹。false表示不會重新入隊列，直接丟棄灸姊。
3.basicReject
basicReject(long deliveryTag, boolean requeue)拱燃，表示拒絕該消息，requeue表示是否重回隊列厨钻，與basicNack的區(qū)別在于不能進行批量拒絕扼雏。
根據(jù)官網(wǎng)的描述：
在basicNack和basicReject中，requeue參數(shù)為false時分別有以下情況：
1.配置了死信隊列
false表示不重新入隊進行消費夯膀，配置了死信隊列诗充，則消息進入死信隊列
2.未配置死信隊列
false表示不重新入隊進行消費，沒有配置了死信隊列诱建，則消息直接刪除丟棄
根據(jù)上面的描述可知蝴蜓，上面的三個確認方法，basicNack和basicReject的requeue=false時俺猿，都會將消息隊列的消息刪除茎匠。
在手動模式下，如果連接中斷押袍、消費異常時诵冒，消息會自動重新入隊：
這種情況下，可能會出現(xiàn)消息冪等性的問題谊惭，即消費者接受到的消息可能是之前傳遞給其他消費者的消息汽馋，但有一個參數(shù)redeliver表示，為true表示是重新消費的圈盔。
在手動和自動模式下豹芯，如果都配置了重試機制，但消費者拋出異常時驱敲，兩種模式的消息重試不同
- 自動模式下铁蹈，消費者拋出異常，消息重新入隊众眨，多次消費失敗了握牧，達到重試上限了，會自動丟棄娩梨。
- 手動模式下我碟，消費者拋出一行，消息重試姚建，但如果消息一直沒有被確認或者拒絕，消息則會處于unacked狀態(tài)吱殉，導致消息積壓掸冤。
消息進入死信隊列的前提是厘托，消息生產隊列需綁定死信隊列，且消息確認為失敗或拒絕時
