消息丟失

1、只要訂單完成我們就會發(fā)送一條消息給MQ，這個途中突然MQ服務(wù)器網(wǎng)絡(luò)中斷，導(dǎo)致消息無法抵達

做好容錯方法需要在消息發(fā)送前加上異常處理

 try {
  rabbitTemplate.convertAndSend("order-event-exchange", "order.release.other", orderTo);
    } 
catch (Exception e) {
   //將沒法送成功的消息進行重試發(fā)送
    }

還可以將消息存入數(shù)據(jù)庫，把失敗的消息定期重新再發(fā)一遍

2、當(dāng)消息發(fā)送給MQ，通過Brock通過交換機抵達隊列，MQ關(guān)機了，只有抵達隊列才能實現(xiàn)消息持久化

這時候需要使用生產(chǎn)者的確認機制

只要消息收到了會自動持久化，如果進入另一個回調(diào)方法說明報錯了，需要修改數(shù)據(jù)庫使消息重發(fā)

3、自動ACK的狀態(tài)下。消費者收到消息，但沒來得及消息然后宕機

一定開啟手動ACK，消費成功才移除，失敗或者沒來得及處理就noAck并重新入隊

消息重復(fù)

1、消息消費成功，事務(wù)已經(jīng)提交，ack時，機器宕機。導(dǎo)致沒有ack成功，Broker的消息重新由unack變?yōu)閞eady，并發(fā)送給其他消費者

在ack的時候宕機，導(dǎo)致消息沒有確認，又需要重新發(fā)送

2、消息消費失敗，由于重試機制，自動又將消息發(fā)送出去

關(guān)閉訂單的時候，沒有成功，又重新進入隊列再次執(zhí)行，這種是可以允許的

解決辦法：

消費者的業(yè)務(wù)消費接口應(yīng)該設(shè)計為冪等性的。比如扣庫存有工作單的狀態(tài)標志
使用防重表（redis/mysql），發(fā)送消息每一個都有業(yè)務(wù)的唯一標識，處理過就不用處理
rabbitMQ的每一個消息都有redelivered字段，可以獲取是否是被重新投遞過來的，而不是第一次投遞過來的

判斷當(dāng)前消息是否是第二次及以后被派發(fā)過來的

消息積壓

消費者宕機積壓

消費者消費能力不足積壓

發(fā)送者發(fā)送流量太大

上線更多的消費者，進行正常消費

上線專門的隊列消費服務(wù)，將消息先批量取出來，記錄數(shù)據(jù)庫，離線慢慢處理

這也是實現(xiàn)了柔性事務(wù)-可靠消息+最終一致性解決方案

做好消息確認機制（生產(chǎn)者、消費者）+手動確認機制

并把消息在數(shù)據(jù)庫做好記錄

總結(jié)

以上是生活随笔為你收集整理的RabbitMQ消息丢失、积压、重复等解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。