消息總線能否實現(xiàn)消息必達？

一、緣起

---

上周討論了兩期環(huán)形隊列的業(yè)務(wù)應(yīng)用：

《高效定時任務(wù)的觸發(fā)》

《延遲消息的快速實現(xiàn)》

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

任務(wù)、延遲消息都放在內(nèi)存里，萬一重啟了怎么辦？

能否保證消息必達？

二、架構(gòu)方向

---

MQ要想盡量消息必達，架構(gòu)上有兩個核心設(shè)計點：

（1）消息落地

（2）消息超時、重傳、確認

三、MQ核心架構(gòu)

---

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

（1）發(fā)送方 -> 左側(cè)粉色部分

（2）MQ核心集群 -> 中間藍色部分

（3）接收方 -> 右側(cè)黃色部分

粉色發(fā)送方又由兩部分構(gòu)成：業(yè)務(wù)調(diào)用方與MQ-client-sender

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

黃色接收方也由兩部分構(gòu)成：業(yè)務(wù)接收方與MQ-client-receiver

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

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

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

（2）MQ將消息投遞給接收方，下半場

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

---

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

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

（1）MQ-client將消息發(fā)送給MQ-server（此時業(yè)務(wù)方調(diào)用的是API：SendMsg）

（2）MQ-server將消息落地，落地后即為發(fā)送成功

（3）MQ-server將應(yīng)答發(fā)送給MQ-client（此時回調(diào)業(yè)務(wù)方是API：SendCallback）

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

（1）MQ-server將消息發(fā)送給MQ-client（此時回調(diào)業(yè)務(wù)方是API：RecvCallback）

（2）MQ-client回復(fù)應(yīng)答給MQ-server（此時業(yè)務(wù)方主動調(diào)用API：SendAck）

（3）MQ-server收到ack，將之前已經(jīng)落地的消息刪除，完成消息的可靠投遞

如果消息丟了怎么辦？

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

上半場的超時與重傳

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

下半場的超時與重傳

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ā)。

五、總結(jié)

---

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

（1）消息收到先落地

（2）消息超時、重傳、確認保證消息必達

有問題隨時溝通交流，后續(xù)講消息去重、冪等性設(shè)計、何時該使用MQ。