@bean
public messagerecoverer messagerecoverer(rabbittemplate rabbittemplate)
public class rejectanddontrequeuerecoverer implements messagerecoverer
throw new listenerexecutionfailedexception("retry policy exhausted", new amqprejectanddontrequeueexception(cause), message);
}}
可以通過給佇列（queue）繫結死信佇列，使用nack反饋給mq，會將訊息**到死信佇列裡面，此種方式需要自己在消費訊息的方法內部將異常處理掉
//宣告佇列，並給佇列增加x-dead-letter-exchange和x-dead-letter-routing-key引數，用於指定死信佇列的路由和routingkey
@bean
public queue queue()
//訊息確認時使用nack，並且requeue引數傳false
channel.basicnack(message.getmessageproperties().getdeliverytag(), false, false);
監聽的方法內丟擲異常貌似沒有太大用處。因為丟擲異常就算是重試也非常有可能會繼續出現異常，當重試次數完了之後訊息就只有重啟應用才能接收到了，很有可能導致訊息消費不及時。當然可以配置republishmessagerecoverer來解決，但是萬一republishmessagerecoverer傳送失敗了呢。。那就可能造成訊息消費不及時了。所以即使需要將處理出現異常的訊息統一放到另外佇列去處理，個人建議兩種方式：
rabbitmq訊息重新入隊和訊息確認
為了確認訊息不會丟失，rabbitmq支援message acknowledgments。乙個ack的響應會從消費端返回，告訴rabbitmq乙個特定的訊息已被接收。當rabbitmq空閒時會處理它，將它刪除。如果乙個消費者掛掉 channel被關閉 connection被關閉或者tcp 連線被關閉...
confirm 確認訊息 return 返回訊息
1.建立乙個connectionfactory，並進行配置。connectionfactory connectionfactory new connectionfactory connectionfactory sethost 192.168.11.76 connectionfactory setp...
RabbitMQ實戰 訊息確認機制之訊息的正確消費
上節中我們講了如何確保訊息的準確發布，今天我們來看看如何確保訊息的正確消費。在之前的基礎上我們對消費者 倉庫服務 進行完善。所以，首先我們將ack的方式設定為手動 spring rabbitmq host xx port 5672 username x password x listener dir...