一、緣起

上周討論了兩期環形隊列的業務應用：

《高效定時任務的觸發》

《延遲消息的快速實現》

兩期的均有大量讀者提問：

• 任務、延遲消息都放在內存里，萬一重啟了怎么辦?
• 能否保證消息必達?

今天就簡單聊聊消息隊列(MsgQueue)的消息必達性架構與流程。

二、架構方向

MQ要想盡量消息必達，架構上有兩個核心設計點：

(1)消息落地

(2)消息超時、重傳、確認

三、MQ核心架構

上圖是一個MQ的核心架構圖，基本可以分為三大塊：

(1)發送方 -> 左側粉色部分

(2)MQ核心集群 -> 中間藍色部分

(3)接收方 -> 右側黃色部分

粉色發送方又由兩部分構成：業務調用方與MQ-client-sender

其中后者向前者提供了兩個核心API：

• SendMsg(bytes[] msg)
• SendCallback()

藍色MQ核心集群又分為四個部分：MQ-server，zk，db，管理后臺web

黃色接收方也由兩部分構成：業務接收方與MQ-client-receiver

其中后者向前者提供了兩個核心API：

• RecvCallback(bytes[] msg)
• SendAck()

MQ是一個系統間解耦的利器，它能夠很好的解除發布訂閱者之間的耦合，它將上下游的消息投遞解耦成兩個部分，如上述架構圖中的1箭頭和2箭頭：

(1)發送方將消息投遞給MQ，上半場

(2)MQ將消息投遞給接收方，下半場

四、MQ消息可靠投遞核心流程

MQ既然將消息投遞拆成了上下半場，為了保證消息的可靠投遞，上下半場都必須盡量保證消息必達。

MQ消息投遞上半場，MQ-client-sender到MQ-server流程見上圖1-3：

• MQ-client將消息發送給MQ-server(此時業務方調用的是API：SendMsg)
• MQ-server將消息落地，落地后即為發送成功
• MQ-server將應答發送給MQ-client(此時回調業務方是API：SendCallback)

MQ消息投遞下半場，MQ-server到MQ-client-receiver流程見上圖4-6：

• MQ-server將消息發送給MQ-client(此時回調業務方是API：RecvCallback)
• MQ-client回復應答給MQ-server(此時業務方主動調用API：SendAck)
• MQ-server收到ack，將之前已經落地的消息刪除，完成消息的可靠投遞

1. 如果消息丟了怎么辦?

MQ消息投遞的上下半場，都可以出現消息丟失，為了降低消息丟失的概率，MQ需要進行超時和重傳。

2. 上半場的超時與重傳

MQ上半場的1或者2或者3如果丟失或者超時，MQ-client-sender內的timer會重發消息，直到期望收到3，如果重傳N次后還未收到，則SendCallback回調發送失敗，需要注意的是，這個過程中MQ-server可能會收到同一條消息的多次重發。

3. 下半場的超時與重傳

MQ下半場的4或者5或者6如果丟失或者超時，MQ-server內的timer會重發消息，直到收到5并且成功執行6，這個過程可能會重發很多次消息，一般采用指數退避的策略，先隔x秒重發，2x秒重發，4x秒重發，以此類推，需要注意的是，這個過程中MQ-client-receiver也可能會收到同一條消息的多次重發。

MQ-client與MQ-server如何進行消息去重，如何進行架構冪等性設計，下一次撰文另述，此處暫且認為為了保證消息必達，可能收到重復的消息。

五、總結

消息總線是系統之間的解耦利器，但切勿濫用，未來也會撰文細究MQ的使用場景，消息總線為了盡量保證消息必達，架構設計方向為：

• 消息收到先落地
• 消息超時、重傳、確認保證消息必達

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文