訊息丟失

1、只要訂單完成我們就會發送一條訊息給MQ，這個途中突然MQ服務器網路中斷，導致訊息無法抵達

做好容錯方法需要在訊息發送前加上例外處理

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

還可以將訊息存入資料庫，把失敗的訊息定期重新再發一遍

2、當訊息發送給MQ，通過Brock通過交換機抵達佇列，MQ關機了，只有抵達佇列才能實作訊息持久化

這時候需要使用生產者的確認機制

RabbitMQ訊息丟失、積壓、重復等解決方案

只要訊息收到了會自動持久化，如果進入另一個回呼方法說明報錯了，需要修改資料庫使訊息重發

3、自動ACK的狀態下，消費者收到訊息，但沒來得及訊息然后宕機

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

訊息重復

1、訊息消費成功，事務已經提交，ack時，機器宕機，導致沒有ack成功，Broker的訊息重新由unack變為ready，并發送給其他消費者

RabbitMQ訊息丟失、積壓、重復等解決方案

在ack的時候宕機，導致訊息沒有確認，又需要重新發送

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

RabbitMQ訊息丟失、積壓、重復等解決方案

關閉訂單的時候，沒有成功，又重新進入佇列再次執行，這種是可以允許的

解決辦法：

消費者的業務消費介面應該設計為冪等性的，比如扣庫存有作業單的狀態標志
使用防重表（redis/mysql），發送訊息每一個都有業務的唯一標識，處理過就不用處理
rabbitMQ的每一個訊息都有redelivered欄位，可以獲取是否是被重新投遞過來的，而不是第一次投遞過來的

RabbitMQ訊息丟失、積壓、重復等解決方案

判斷當前訊息是否是第二次及以后被派發過來的

訊息積壓

消費者宕機積壓
消費者消費能力不足積壓
發送者發送流量太大上線更多的消費者，進行正常消費上線專門的佇列消費服務，將訊息先批量取出來，記錄資料庫，離線慢慢處理

這也是實作了柔性事務-可靠訊息+最終一致性解決方案

做好訊息確認機制（生產者、消費者）+手動確認機制

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/348305.html

標籤：其他

上一篇：kafka rebalance 總結說明圖

下一篇：centos7安裝hadoop集群（親測可用）