RabbitMQ生產端保證消息100%投遞成功

什麼是生產端的可靠性投遞

1. 保證消息成功發出
2. 保證MQ節點的成功接收
3. 發送端收到MQ節點(borker)的確認應答
4. 完善的消息補償機制

互聯網大廠生產端可靠性投遞方案

消息落庫對消息狀態進行打標

1. 生產者將業務數據和消息入庫，並設置信息狀態爲0，即初始待投遞
2. 生產者將消息發送至broker
3. broker向生產者發送確認
4. 生產者收到broker確認後修改消息狀態爲1，即消息投遞成功
5. 系統定時任務掃描未投遞成功的消息
6. 生產者將爲成功投遞的消息重發給broker，並記錄重發次數
7. 當重發次數大於3時，此時修改消息狀態爲2，即投遞失敗。對於投遞失敗的消息啓用補償機制或人工去處理失敗消息

存在問題

在高併發場景下，每次要對業務數據和消息數據入庫，數據庫會遇到瓶頸。故採用下面的消息的延遲投遞，作二次檢查，回調確認的方案。

消息的延遲投遞，作二次檢查，回調確認

1. 先將業務數據入庫
2. 生產者第一次向broker發送消息
3. 生產者第二次向broker發送check延遲消息，通常按本身業務設爲2min-5min.
4. Consumer從messageQueue獲取消息
5. Consumer成功消費消息後，向broker發送確認消息(設其隊列名爲ConsumerQueueConfirm)
6. CallbackService監聽ConsumerQueueConfirm，並將成功消費的消息入庫MSG DB
7. 同時CallbackService監聽checkdetailQueue,並去MSG DB查詢該消息是否被成功消費
8. 若查詢不到check message，則CallbackService向ProducerService發送RPC請求，讓其重發消息，設置重發次數，達到重發次數後，設置其爲消費失敗
9. 人工處理因網絡閃斷或者業務問題產生的未成功消費消息，系統消息投遞幾乎達到100%

注意

1. 互聯網大廠通常不會考慮分佈式事務，都用補償機制。
2. 在高併發下，少作一次數據庫持久操做，提升系統處理能力，故將業務和消息的持久化拆開。