上一章和大家分享了《http如何像tcp一樣實時的收消息?》， 本章來聊一聊即時通訊(Instant Messaging，后簡稱im)消息的可靠投遞。

一、報文類型

im的客戶端與服務器通過發(fā)送報文(也就是網(wǎng)絡包)來完成消息的傳遞，報文分為三種

請求報文(request，后簡稱為為R)

應答報文(acknowledge，后簡稱為A)

通知報文(notify，后簡稱為N)，這三種報文的解釋如下：

R：客戶端主動發(fā)送給服務器的報文

A：服務器被動應答客戶端的報文，一個A對應一個R

N：服務器主動發(fā)送給客戶端的報文

二、普通消息投遞流程

用戶A給用戶B發(fā)送一個“你好”，流程如下：

 

 

1)client-A向im-server發(fā)送一個消息請求包，即msg:R

2)im-server在成功處理后，回復client-A一個消息響應包，即msg:A

3)如果此時client-B在線，則im-server主動向client-B發(fā)送一個消息通知包，即msg:N(當然，如果client-B不在線，則消息會存儲離線)

三、上述消息投遞流程出現(xiàn)的問題

從流程圖中容易看到，發(fā)送方client-A收到msg:A后，只能說明im-server成功接收到了消息，并不能說明client-B接收到了消息。在若干場景下，可能出現(xiàn)msg:N包丟失，且發(fā)送方client-A完全不知道，例如：

1)服務器崩潰，msg:N包未發(fā)出

2)網(wǎng)絡抖動，msg:N包被網(wǎng)絡設備丟棄

3)client-B崩潰，msg:N包未接收

結(jié)論是悲觀的：接收方client-B是否有收到msg:N，發(fā)送方client-A完全不可控，那怎么辦呢?

四、應用層確認+im消息可靠投遞的六個報文

upd是一種不可靠的傳輸層協(xié)議，tcp是一種可靠的傳輸層協(xié)議，tcp是如何做到可靠的?答案是：超時、重傳、確認。

要想實現(xiàn)應用層的消息可靠投遞，必須加入應用層的確認機制，即：要想讓發(fā)送方client-A確保接收方client-B收到了消息，必須讓接收方client-B給一個消息的確認，這個應用層的確認的流程，與消息的發(fā)送流程類似：

 

 

4)client-B向im-server發(fā)送一個ack請求包，即ack:R

5)im-server在成功處理后，回復client-B一個ack響應包，即ack:A

6)則im-server主動向client-A發(fā)送一個ack通知包，即ack:N

至此，發(fā)送“你好”的client-A，在收到了ack:N報文后，才能確認client-B真正接收到了“你好”。

會發(fā)現(xiàn)，一條消息的發(fā)送，分別包含(上)(下)兩個半場，即msg的R/A/N三個報文，ack的R/A/N三個報文，一個應用層即時通訊消息的可靠投遞，共涉及6個報文，這就是im系統(tǒng)中消息投遞的最核心技術(shù)。

五、可靠消息投遞存在什么問題

期望六個報文完成消息的可靠投遞，但實際情況，msg:N，ack:N這兩個報文都可能丟失(原因如第二章所述，可能是服務器奔潰、網(wǎng)絡抖動、或者客戶端奔潰)，此時client-A都收不到期待的ack:N報文，即client-A不能確認client-B是否收到“你好”，但這兩個報文的丟失對應的業(yè)務影響又大有不同：

1)msg:N包丟失，業(yè)務結(jié)果是client-B沒有收到消息

2)ack:N包丟失，業(yè)務結(jié)果是client-B收到了消息，只是client-A不知道而已

那怎么辦呢?

六、消息的超時與重傳

client-A發(fā)出了msg:R，收到了msg:A之后，在一個期待的時間內(nèi)，如果沒有收到ack:N，client-A會嘗試將msg:R重發(fā)。可能client-A同時發(fā)出了很多消息，故client-A需要在本地維護一個等待ack隊列，并配合timer超時機制，來記錄哪些消息沒有收到ack:N，以定時重發(fā)。

 

 

一旦收到了ack:N，說明client-B收到了“你好”消息，對應的消息將從“等待ack隊列”中移除。

七、消息的重傳存在什么問題

第五章提到過，msg:N，ack:N都有可能丟失：

1)msg:N報文丟失，說明client-B之前壓根沒有收到“你好”報文，超時與重傳機制十分有效

2)ack:N報文丟失，說明client-B之前已經(jīng)收到了“你好”報文(只是client-A不知道而已)，超時與重傳機制將導致client-B收到重復的消息，那怎么辦呢?

八、消息的去重

解決方法也很簡單，由發(fā)送方client-A生成一個消息去重的msgid，保存在“等待ack隊列”里，同一條消息使用相同的msgid來重傳，供client-B去重，而不影響用戶體驗。

九、其他

1)上述設計理念，由客戶端重傳，可以保證服務端無狀態(tài)性(架構(gòu)設計基本準則)

2)如果client-B不在線，im-server保存了離線消息后，要偽造ack:N發(fā)送給client-A

十、總結(jié)

1)im系統(tǒng)是通過超時、重傳、確認、去重的機制來保證消息的可靠投遞，不丟不重

2)一個“你好”的發(fā)送，包含上半場msg:R/A/N與下半場ack:R/A/N的6個報文

3)im系統(tǒng)難以做到系統(tǒng)層面的不丟不重，只能做到業(yè)務層面的不丟不重

文章轉(zhuǎn)載自微信公眾號“架構(gòu)師之路”