使用消息隊列進行限流（中） - 如何避免消息丟失

在公衆號回覆課程,免費獲取JAVA全棧課程

做者 | 顏羣java

公衆號 | 大數據和人工智能技術web

上篇文章介紹了使用MQ限流的基本思路，詳情請戳使用消息隊列進行限流（上）。面試

而且在上篇文末，遺留了三個問題：在發送消息的過程當中，如何避免消息丟失、消息被重複消費，如何處理消息積壓問題？數據庫

本文主要解決第一個問題：如何避免消息丟失編程

在消息隊列中，每條消息都會經生產者發送給MQ，最終再轉發給消費者。所以每條消息在發送時都至少會被傳遞兩次，而每次的消息傳遞都會因爲網絡異常等狀況形成傳遞失敗，所以消息在傳遞時就存在丟失的可能。那麼該如何避免消息丟失呢？微信

消息在發送時至少會被傳遞兩次，然而傳輸過程受網絡環境、網絡設備等外界因素影響，是咱們沒法在代碼層面進行干預的，所以咱們只能在兩次傳輸所通過的三個端點採起措施，如圖。網絡

1.第一次消息傳輸階段架構

主要經過「生產者」和「MQ」兩端的反饋標記來保證正常的傳輸（相似TPC協議的三次握手機制）。目前主流的MQ都可以在接收到消息後，給生產者回傳一個反饋標記，如圖。併發

生產者在收到反饋標記後，就能夠判斷第一次消息傳輸是否成功。若是失敗，就應該啓動消息補償機制從新再發一次。若是補償了屢次後依舊傳輸失敗，就能夠考慮丟棄此消息，並給用戶響應一個失敗信息，表示這次傳輸失敗，提示用戶從新發起一次請求。app

提示：有些MQ在發送消息時支持事務機制，即只有發送成功的消息纔會被提交，發送失敗的消息會自動回滾。這樣的確能夠很輕鬆的API層面解決消息丟失的問題，可是這種將全部消息都歸入事務管理的作法會下降MQ的吞吐量，所以在併發量很是大的秒殺系統中是不建議開啓的。

MQ在接收消息後，除了給生產者回傳反饋標記之外，還應該將接收到的消息以異步的方式持久化到硬盤或數據庫中，防止MQ宕機形成的數據丟失。此外MQ還要注意執行的順序問題，最好是先持久化消息，以後再回傳反饋標記。這樣一來，即便回傳反饋標記後MQ馬上宕機，MQ也能在恢復啓動後從硬盤（或數據庫）中從新讀取消息。

2.第二次消息傳輸階段

當MQ接收了消息，並將消息持久化了之後，剩下的就很是簡單了。消費只須要在接收到消息後，用一樣的方式給MQ回傳一個反饋標記，就能確保整個消息傳遞過程的完整性。