[TOC] ## MQ消息可靠投遞核心流程 MQ既然將消息投遞拆成了上下半場，為了保證消息的可靠投遞，上下半場都必須盡量保證消息必達。  **上半場**，MQ-client-sender到MQ-server流程見上圖 1-3： 1. MQ-client將消息發送給MQ-server（此時業務方調用的是API：SendMsg） 2. MQ-server將消息落地，落地后即為發送成功 3. MQ-server將應答發送給MQ-client（此時回調業務方是API：SendCallback） **下半場**，MQ-server到MQ-client-receiver流程見上圖 4-6： 1. MQ-server將消息發送給MQ-client（此時回調業務方是API：RecvCallback） 2. MQ-client回復應答給MQ-server（此時業務方主動調用API：SendAck） 3. MQ-server收到ack，將之前已經落地的消息刪除，完成消息的可靠投遞 ### 如果消息丟了怎么辦 為了降低消息丟失的概率，MQ需要進行超時和重傳 ### 上半場的超時與重傳 MQ上半場的1或者2或者3如果丟失或者超時，MQ-client-sender內的timer會重發消息，直到期望收到3，如果重傳N次后還未收到，則SendCallback回調發送失敗，需要注意的是，這個過程中MQ-server可能會收到同一條消息的多次重發。 ### 下半場的超時與重傳 MQ下半場的4或者5或者6如果丟失或者超時，MQ-server內的timer會重發消息，直到收到5并且成功執行6，這個過程可能會重發很多次消息，一般采用指數退避的策略，先隔x秒重發，2x秒重發，4x秒重發，以此類推，需要注意的是，這個過程中MQ-client-receiver也可能會收到同一條消息的多次重發。 ## 保證冪等  為保證消息的可達性，超時、重傳、確認機制可能導致消息總線、或者業務方收到重復的消息，從而對業務產生影響 ### 上半場的冪等性設計 一句話:MQ-client生成inner-msg-id，保證上半場冪等 MQ消息發送上半場，即上圖中的1-3 1. 發送端MQ-client將消息發給服務端MQ-server 2. 服務端MQ-server將消息落地 3. 服務端MQ-server回ACK給發送端MQ-client 如果3丟失，發送端MQ-client超時后會重發消息，可能導致服務端MQ-server收到重復消息。 此時重發是MQ-client發起的，消息的處理是MQ-server，為了避免步驟2落地重復的消息，對每條消息，MQ系統內部必須生成一個inner-msg-id，作為去重和冪等的依據，這個內部消息ID的特性是： - 全局唯一 - MQ生成，具備業務無關性，對消息發送方和消息接收方屏蔽 有了這個inner-msg-id，就能保證上半場重發，也只有1條消息落到MQ-server的DB中，實現上半場冪等 ### 下半場的冪等性設計 一句話:業務發送方帶入biz-id，業務接收方去重保證冪等。 MQ消息發送下半場，即上圖中的4-6 4. 服務端MQ-server將消息發給接收端MQ-client 5. 接收端MQ-client回ACK給服務端 6. 服務端MQ-server將落地消息刪除 需要強調的是，接收端MQ-client回ACK給服務端MQ-server，是消息消費業務方的主動調用行為，不能由MQ-client自動發起，因為MQ系統不知道消費方什么時候真正消費成功。 如果5丟失，服務端MQ-server超時后會重發消息，可能導致MQ-client收到重復的消息。 此時重發是MQ-server發起的，消息的處理是消息消費業務方，消息重發勢必導致業務方重復消費（上例中的一次付款，重復發卡），為了保證業務冪等性，業務消息體中，必須有一個biz-id，作為去重和冪等的依據，這個業務ID的特性是： - 對于同一個業務場景，全局唯一 - 由業務消息發送方生成，業務相關，對MQ透明 - 由業務消息消費方負責判重，以保證冪等 最常見的業務ID有：支付ID，訂單ID，帖子ID等。 具體到支付購卡場景，發送方必須將支付ID放到消息體中，消費方必須對同一個支付ID進行判重，保證購卡的冪等。 有了這個業務ID，才能夠保證下半場消息消費業務方即使收到重復消息，也只有1條消息被消費，保證了冪等