MQ,究竟如何保證消息冪等?
MQ的核心架構如何?
MQ核心架構,它由發送端、服務端、固化存儲、接收端四大部分組成。
MQ如何保證消息必達?
MQ消息必達,架構上有兩個核心設計點:
- 消息落地;
- 消息超時、重傳、確認;
畫外音:詳見核心架構中的步驟1-6。
MQ消息重傳,是否可能導致重復的消息?
有可能。
為保證消息的可達性,超時、重傳、確認機制可能導致MQ、或者業務方收到重復的消息,從而對業務產生影響。
舉個栗子:購買會員卡,上游支付系統負責給用戶扣款,下游系統負責給用戶發卡,通過MQ異步通知。不管是上半場的ACK丟失,導致MQ收到重復的消息,還是下半場ACK丟失,導致購卡系統收到重復的購卡通知,都可能出現,上游扣了一次錢,下游發了多張卡。
為了避免對業務的影響,MQ如何保證冪等性?
MQ的冪等性,由兩部分構成:
- MQ發送端,到MQ-server的冪等性(上半場);
- MQ-server,到MQ接收端的冪等性(下半場);
上半場消息發送,如何保證冪等性?
MQ消息發送上半場,即上圖中的1-3:
- 發送端MQ-client將消息發給服務端MQ-server;
- 服務端MQ-server將消息落地;
- 服務端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中,實現上半場冪等。
下半場消息發送,如何保證冪等性?
MQ消息發送下半場,即上圖中的4-6:
- 服務端MQ-server將消息發給接收端MQ-client;
- 接收端MQ-client回ACK給服務端;
- 服務端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條消息被消費,保證了冪等。
總結,MQ如何保證消息冪等?
首先,上半場冪等。
MQ-client生成inner-msg-id,保證上半場冪等。
這個ID全局唯一,業務無關,由MQ保證。
然后,下半場冪等。
業務發送方帶入biz-id,業務接收方去重保證冪等。
這個ID對單業務唯一,業務相關,對MQ透明。
因此,冪等性,不僅對MQ有要求,對業務上下游也有要求。
【本文為51CTO專欄作者“58沈劍”原創稿件,轉載請聯系原作者】