從客戶端的角度來談談移動端IM的消息可靠性和送達機制

TCP協(xié)議的可靠性之外還會出現(xiàn)消息丟失？

如何確保 IM 不丟消息是個相對復雜的話題，從客戶端發(fā)送數(shù)據(jù)到服務器，再從服務器抵達目標客戶端，最終在 UI 成功展示，其間涉及的環(huán)節(jié)很多，這里只取其中一環(huán)「接收端如何確保消息不丟失」來探討，粗略聊下我接觸過的兩種設計思路。

說到可靠抵達，第一反應會聯(lián)想到 TCP 的 reliability。數(shù)據(jù)可靠抵達是個通用性的問題，無論是網(wǎng)絡二進制流數(shù)據(jù)，還是上層的業(yè)務數(shù)據(jù)，都有可靠性保障問題，TCP 作為網(wǎng)絡基礎設施協(xié)議，其可靠性設計的可靠性是毋庸置疑的，我們就從 TCP 的可靠性說起。

在 TCP 這一層，所有 Sender 發(fā)送的數(shù)據(jù)，每一個 byte 都有標號（Sequence Number），每個 byte 在抵達接收端之后都會被接收端返回一個確認信息（Ack Number）， 二者關系為 Ack = Seq + 1。簡單來說，如果 Sender 發(fā)送一個 Seq = 1，長度為 100 bytes 的包，那么 receiver 會返回一個 Ack = 101 的包，如果 Sender 收到了這個Ack 包，說明數(shù)據(jù)確實被 Receiver 收到了，否則 Sender 會采取某種策略重發(fā)上面的包。

第一個問題是：現(xiàn)在的 IM App 幾乎都是走 TCP 通道，既然 TCP 本身是具備可靠性的，為什么還會出現(xiàn)消息接收端（Receiver）丟失消息的情況，看下圖一目了然：

一句話總結上圖的含義：網(wǎng)絡層的可靠性不等同于業(yè)務層的可靠性。

數(shù)據(jù)可靠抵達網(wǎng)絡層之后，還需要一層層往上移交處理，可能的處理有：安全性校驗，binary 解析，model 創(chuàng)建，寫 db，存入 cache，UI 展示，以及一些 edge cases（斷網(wǎng)，用戶 logout，disk full，OOM，crash，關機。。） 等等，項目的 feature 越多，網(wǎng)絡層往上的處理出錯的可能性就越大。

舉個最簡單的場景為例子：消息可靠抵達網(wǎng)絡層之后，寫 db 之前 App crash（不稀奇，是 App 都會 crash），雖然數(shù)據(jù)在網(wǎng)絡層可靠抵達了，但沒存進 db，下次用戶打開 App 消息自然就丟失了，如果不在業(yè)務層再增加可靠性保障，網(wǎng)絡層面不會重發(fā)，那么意味著這條消息對于 Receiver 永遠丟失了。

客戶端方案1：應用層 Ack 消息

這個方案可以簡單理解為，將 TCP 的 Ack 流程再走一遍，在應用層也構建一個 Ack 消息，在應用層可靠性得到確認（一般以存入 db 為準，更準確說是事務提交成功的回調(diào)函數(shù)）之后再發(fā)送這個 Ack 消息，Server 收到應用層 Ack 消息之后才認為 Receiver 已收到，否則也采取某種策略重發(fā)消息。

具體到 IM App 當中，接收端接受到 Server 的 Message，將 Message 存入 db，在確認回調(diào)里發(fā)送 Ack Receive 消息，Server 收到 Ack Receive 即認為消息已經(jīng)可靠抵達，否則會在某個時機重新推送（比如客戶端重連服務器時候 Pull，比如有新消息時 Server Push）。

客戶端方案2：應用層 Seq ID

這個方案和上面不同，但也是在應用層操作。我們個每個 Message 分配一個 Seq ID，這個 Seq ID 對于單個用戶的接受消息隊列來說是連續(xù)的，如果 Message A 和 Message B 是相鄰的，那么 MsgBSeqID = MsgASeqID + 1。每次存入 db 的時候更新 db 里的 LastReceivedSeqID，LastReceivedSeqID 即為上一條寫入數(shù)據(jù)庫消息的 Seq ID。

這么做的好處是，每次從網(wǎng)絡層收到消息時，從 db 里取出 LastReceivedSeqID，如果 LastReceivedSeqID = 新消息 Seq ID - 1，那么說明應用層消息時連續(xù)的沒有發(fā)生丟失。還可以對收到的批量消息做預檢測，檢查消息隊列里的 Seq ID 是否為聯(lián)系的，只要存在任何一種不連續(xù)的 Seq ID 情況，就說明發(fā)送了丟失，此時接收端可以用 LastReceivedSeqID 從 Server 重新獲取準確的接受消息隊列。

這么做的好處是避免了每次都需要發(fā)送一條 Ack 消息，壞處是應用層邏輯復雜之后，一旦出現(xiàn) Seq ID 不連續(xù)的情況，會過度依賴于 refetch，難以分析問題出現(xiàn)的原因，refetch 一旦過于頻繁，其流量損耗極有可能大于 Ack 消息的數(shù)據(jù)量。

本文小結

消息的可靠抵達可以抽象為更一般意義上的可靠性問題，工程上總會碰到需要解決各種形式可靠性問題的場景，以經(jīng)典計算機理論或者實踐為基礎來分析應用層的工程問題，可以舉一反三，藥到病除。

在工程上實踐可靠性，需要線了解工程的每一個環(huán)節(jié)以及數(shù)據(jù)如何在各個環(huán)節(jié)流動，接下來才是分析每一個環(huán)節(jié)數(shù)據(jù)出錯的可能性。檢驗可靠性的標準時「入袋為安」，存入 db 或者以其他方式持久化到 disk 當中，這樣才能保證客戶端每次都能正確讀取到消息。

另外，可靠性可以理解為兩方面：

· 一是數(shù)據(jù)可靠抵達（沒有任何中間數(shù)據(jù)被丟失）；

· 二是正確抵達（沒有亂序或者數(shù)據(jù)更改）。

其實理論上 TCP 也不是 100% 可靠（數(shù)據(jù)有可能在傳輸時改變而無法被檢測到），而是 100% 工程上可靠（數(shù)據(jù)改變而不被檢測到時個極小概率的事件），這是另外一個有意思的話題。