>[info] 如何保證消息的100%接收(一) **Producer 的可靠性投遞要求** * 保證消息的成功發出 * 保證MQ節點的成功接收 * 發送端收到MQ節點(Broker) 確認應答 * 完善的消息補償機制 ***** **解決方案：** 方案一：消息信息落庫,對消息狀態進行打標 (常見方案) * 將消息持久化到DB并設置狀態值,收到Consumer的應答就改變當前記錄的狀態. * 再輪詢重新發送沒接收到應答的消息,注意這里要設置重試次數. **方案流程圖：** 狀態為：0 發送失敗 1 發送成功 ](images/screenshot_1627025877313.png) **方案實現流程：** 比如我下單成功 * step1 - 對訂單數據入BIZ DB訂單庫,并對因此生成的業務消息入MSG DB消息庫 此處由于采用了兩個數據庫,需要兩次持久化操作,為了保證數據的一致性,有人可能就想著采用分布式事務,但在大廠實踐中,基本都是采用補償機制! >[] 這里一定要保證step1 中消息都存儲成功了，沒有出現任何異常情況，然后生產端再進行消息發送。如果失敗了就進行快速失敗機制 對業務數據和消息入庫完畢就進入 * setp2 - 發送消息到 MQ 服務上，如果一切正常無誤消費者監聽到該消息，進入 * step3 - 生產端有一個 Confirm Listener ,異步監聽Broker回送的響應,從而判斷消息是否投遞成功 * step4 - 如果成功,去數據庫查詢該消息,并將消息狀態更新為1 * step5 - 如果出現意外情況，消費者未接收到或者 Listener 接收確認時發生網絡閃斷，導致生產端的Listener就永遠收不到這條消息的confirm應答了，也就是說這條消息的狀態就一直為0了，這時候就需要用到我們的 分布式定時任務來從 MSG 數據庫抓取那些超時了還未被消費的消息，重新發送一遍 此時我們需要設置一個規則，比如說消息在入庫時候設置一個臨界值timeout，5分鐘之后如果還是0的狀態那就需要把消息抽取出 來。這里我們使用的是分布式定時任務，去定時抓取DB中距離消息創建時間超過5分鐘的且狀態為0的消息。 * step6 - 把抓取出來的消息進行重新投遞(Retry Send)，也就是從第二步開始繼續往下走 * step7 - 當然有些消息可能就是由于一些實際的問題無法路由到Broker，比如routingKey設置不對，對應的隊列被誤刪除了，那么這種消息即使重試多次也仍然無法投遞成功，所以需要對重試次數做限制，比如限制3次， 如果投遞次數大于三次，那么就將消息狀態更新為2，表示這個消息最終投遞失敗,然后通過補償機制，人工去處理。實際生產中，這種情況還是比較少的，但是你不能沒有這個補償機制，要不然就做不到可靠性了。 ***** **優缺點：** * 缺點是：生產者在第一步需要更新或者插入操作數據庫，生產監聽器，對用戶體驗下降。 * 在大廠中 都不會加事務，都是進行的補償操作。 * 優化：不需要消息進行持久化 只需要業務持久化