消息總線能否實現(xiàn)消息必達?
一、緣起
上周討論了兩期環(huán)形隊列的業(yè)務應用:
兩期的均有大量讀者提問:
- 任務、延遲消息都放在內(nèi)存里,萬一重啟了怎么辦?
- 能否保證消息必達?
今天就簡單聊聊消息隊列(MsgQueue)的消息必達性架構與流程。
二、架構方向
MQ要想盡量消息必達,架構上有兩個核心設計點:
(1)消息落地
(2)消息超時、重傳、確認
三、MQ核心架構
上圖是一個MQ的核心架構圖,基本可以分為三大塊:
(1)發(fā)送方 -> 左側粉色部分
(2)MQ核心集群 -> 中間藍色部分
(3)接收方 -> 右側黃色部分
粉色發(fā)送方又由兩部分構成:業(yè)務調(diào)用方與MQ-client-sender
其中后者向前者提供了兩個核心API:
- SendMsg(bytes[] msg)
- SendCallback()
藍色MQ核心集群又分為四個部分:MQ-server,zk,db,管理后臺web
黃色接收方也由兩部分構成:業(yè)務接收方與MQ-client-receiver
其中后者向前者提供了兩個核心API:
- RecvCallback(bytes[] msg)
- SendAck()
MQ是一個系統(tǒng)間解耦的利器,它能夠很好的解除發(fā)布訂閱者之間的耦合,它將上下游的消息投遞解耦成兩個部分,如上述架構圖中的1箭頭和2箭頭:
(1)發(fā)送方將消息投遞給MQ,上半場
(2)MQ將消息投遞給接收方,下半場
四、MQ消息可靠投遞核心流程
MQ既然將消息投遞拆成了上下半場,為了保證消息的可靠投遞,上下半場都必須盡量保證消息必達。
MQ消息投遞上半場,MQ-client-sender到MQ-server流程見上圖1-3:
- MQ-client將消息發(fā)送給MQ-server(此時業(yè)務方調(diào)用的是API:SendMsg)
- MQ-server將消息落地,落地后即為發(fā)送成功
- MQ-server將應答發(fā)送給MQ-client(此時回調(diào)業(yè)務方是API:SendCallback)
MQ消息投遞下半場,MQ-server到MQ-client-receiver流程見上圖4-6:
- MQ-server將消息發(fā)送給MQ-client(此時回調(diào)業(yè)務方是API:RecvCallback)
- MQ-client回復應答給MQ-server(此時業(yè)務方主動調(diào)用API:SendAck)
- MQ-server收到ack,將之前已經(jīng)落地的消息刪除,完成消息的可靠投遞
1. 如果消息丟了怎么辦?
MQ消息投遞的上下半場,都可以出現(xiàn)消息丟失,為了降低消息丟失的概率,MQ需要進行超時和重傳。
2. 上半場的超時與重傳
MQ上半場的1或者2或者3如果丟失或者超時,MQ-client-sender內(nèi)的timer會重發(fā)消息,直到期望收到3,如果重傳N次后還未收到,則SendCallback回調(diào)發(fā)送失敗,需要注意的是,這個過程中MQ-server可能會收到同一條消息的多次重發(fā)。
3. 下半場的超時與重傳
MQ下半場的4或者5或者6如果丟失或者超時,MQ-server內(nèi)的timer會重發(fā)消息,直到收到5并且成功執(zhí)行6,這個過程可能會重發(fā)很多次消息,一般采用指數(shù)退避的策略,先隔x秒重發(fā),2x秒重發(fā),4x秒重發(fā),以此類推,需要注意的是,這個過程中MQ-client-receiver也可能會收到同一條消息的多次重發(fā)。
MQ-client與MQ-server如何進行消息去重,如何進行架構冪等性設計,下一次撰文另述,此處暫且認為為了保證消息必達,可能收到重復的消息。
五、總結
消息總線是系統(tǒng)之間的解耦利器,但切勿濫用,未來也會撰文細究MQ的使用場景,消息總線為了盡量保證消息必達,架構設計方向為:
- 消息收到先落地
- 消息超時、重傳、確認保證消息必達
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件,轉載請聯(lián)系原作者】