本文由阿里閑魚技術團隊景松分享，原題“到達率99.9%：閑魚消息在高速上換引擎（集大成）”，有修訂和改動，感謝作者的分享。
1、引言
在2020年年初的時候接手了閑魚的IM即時消息系統，當時的消息存在各種問題，網上的用戶輿情也是接連不斷。
典型的問題，比如：
- 1）“聊天消息經常丟失”；
- 2）“消息用戶頭像亂了”；
- 3）“訂單狀態不對”（相信現在看文章的你還在吐槽閑魚的消息）。
所以閑魚的即時消息系統穩定性、可靠性是一個亟待解決的問題。
我們調研了集團內的一些解決方案，例如釘釘的IMPass。如果貿然直接遷移，技術成本和風險都是比較大，包括服務端數據需要雙寫、新老版本兼容等。
那么基于閑魚現有的即時消息系統架構和技術體系，如何來優化它的消息穩定性、可靠性？應該從哪里開始治理？當前系統現狀到底是什么樣？如何客觀進行衡量？希望本文能讓大家看到一個不一樣的閑魚即時消息系統。
PS：如果您對IM消息可靠性還沒有概念，建議先閱讀這篇入門文章《零基礎IM開發入門(三)：什么是IM系統的可靠性？》。
（本文同步發布于：http://www.52im.net/thread-3706-1-1.html）
2、系列文章
本文是系列文章的第4篇，總目錄如下：
3、行業方案
經過查閱網上分享的主流消息可靠投遞技術方案，我進行了簡單總結。
通常IM消息的投遞鏈路大致分為三步：
- 1）發送者發送；
- 2）服務端接收然后落庫；
- 3）服務端通知接收端。
特別是移動端的網絡環境比較復雜：
- 1）可能你發著消息，網絡突然斷掉了；
- 2）可能消息正在發送中，網絡突然好了，需要重發。
技術原理圖大如下：
PS：可能很多人對移動網絡的復雜性沒有個系統的認知，以下文章有必要系統閱讀：
- 《通俗易懂，理解移動網絡的“弱”和“慢”》
- 《史上最全移動弱網絡優化方法總結》
- 《為什么WiFi信號差？一文即懂！》
- 《為什么手機信號差？一文即懂！》
- 《高鐵上無線上網有多難？一文即懂！》
那么，在如此復雜的網絡環境下，是如何穩定可靠的進行IM消息投遞的？
對于發送者來說，它不知道消息是否有送達，要想做到確定送達，就需要加一個響應機制。
這個機制類似于下面的響應邏輯：
- 1）發送者發送了一條消息“Hello”，進入等待狀態；
- 2）接收者收到這條消息“Hello”，然后告訴發送者說我已經收到這條消息了的確認信息；
- 3）發送者接收到確認信息后，這個流程就算完成了，否則會重試。
上面流程看似簡單，關鍵是中間有個服務端轉發過程，問題就在于誰來回這個確認信息，以及什么時候回這個確認信息。
網上查到比較多的是如下一個消息必達模型：
各報文類型解釋如下：
如上面兩圖所示，發送流程是：
- 1）A向IM-server發送一個消息請求包，即msg:R1；
- 2）IM-server在成功處理后，回復A一個消息響應包，即msg:A1；
- 3）如果此時B在線，則IM-server主動向B發送一個消息通知包，即msg:N1（當然，如果B不在線，則消息會存儲離線）。
如上面兩圖所示，接收流程是：
- 1）B向IM-server發送一個ack請求包，即ack:R2；
- 2）IM-server在成功處理后，回復B一個ack響應包，即ack:A2；
- 3）IM-server主動向A發送一個ack通知包，即ack:N2。
正如上述模型所示：一個可靠的消息投遞機制就是靠的6條報文來保證的，中間任何一個環節出錯，都可以基于這個request-ack機制來判定是否出錯并重試。
我們最終采用的方案也正是參考了上面這個模型，客戶端發送的邏輯是直接基于http的所以暫時不用做重試，主要是在服務端往客戶端推送的時候，會加上重試的邏輯。
限于篇幅，本文就不詳細展開，有興趣可以系統學習以下幾篇：
- 《從客戶端的角度來談談移動端IM的消息可靠性和送達機制》
- 《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
- 《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
- 《完全自已開發的IM該如何設計“失敗重試”機制？》
- 《一套億級用戶的IM架構技術干貨(下篇)：可靠性、有序性、弱網優化等》
- 《理解IM消息“可靠性”和“一致性”問題，以及解決方案探討》
- 《融云技術分享：全面揭秘億級IM消息的可靠投遞機制》
4、當前面臨的具體問題
4.1 概述
在解決消息可靠投遞這個問題之前，我們肯定首先應該搞清楚當前面臨的具體問題到底有哪些。
然而在接手這套即時消息系統時，并沒有相關的準確數據可供參考，所以當前第一步還是要對這套消息系統做一個完整的排查，于是我們對消息做了全鏈路埋點。
具體的埋點環節如下：
基于消息的整個鏈路，我們梳理出來了幾個關鍵的指標：
- 1）發送成功率；
- 2）消息到達率；
- 3）客戶端落庫率。
這次整個數據的統計都是基于埋點來做的，但在埋點的過程中發現了一個很大的問題：當前這套即時消息系統沒有一個全局唯一的消息ID。這導致在全鏈路埋點的過程中，無法唯一確定這條消息的生命周期。
4.2 消息唯一性問題
如上圖所示，當前的消息是通過3個變量來確定唯一性的：
- 1）SessionID: 當前會話的ID；
- 2）SeqID：用戶當前本地發送的消息序號，服務端是不關心此數據，完全是透傳；
- 3）Version：這個比較重要，是消息在當前會話中的序號，已服務端為準，但是客戶端也會生成一個假的version。
以上圖為例：當A和B同時發送消息的時候，都會在本地生成如上幾個關鍵信息，當A發送的消息（黃色）首先到達服務端，因為前面沒有其他version的消息，所以會將原數據返回給A，客戶端A接收到消息的時候，再跟本地的消息做合并，只會保留一條消息。同時服務端也會將此消息發送給B，因為B本地也有一個version=1的消息，所以服務端過來的消息就會被過濾掉，這就出現消息丟失的問題。
當B發送消息到達服務端后，因為已經有version=1的消息，所以服務端會將B的消息version遞增，此時消息的version=2。這條消息發送給A，和本地消息可以正常合并。但是當此消息返回給B的時候，和本地的消息合并，會出現2條一樣的消息，出現消息重復，這也是為什么閑魚之前總是出現消息丟失和消息重復最主要的原因。
4.3 消息推送邏輯問題
當前消息的推送邏輯也存在很大的問題，發送端因為使用http請求，發送的消息內容基本不會出問題，問題是出現在服務端給另外一端推送的時候。
如下圖所示：
如上圖所示：服務端在給客戶端推送的時候，會先判斷此時客戶端是否在線，如果在線才會推送，如果不在線就會推離線消息。
這個做法就非常的簡單粗暴：長連接的狀態如果不穩定，導致客戶端真實狀態和服務端的存儲狀態不一致，就導致消息不會推送到端上。
4.4 客戶端邏輯問題
除了以上跟服務端有關系外，還有一類問題是客戶端本身設計的問題。
可以歸結為以下幾種情況：
- 1）多線程問題：反饋消息列表頁面會出現布局錯亂，本地數據還沒有完全初始化好，就開始渲染界面；
- 2）未讀數和小紅點的計數不準：本地的顯示數據和數據庫存儲的不一致；
- 3）消息合并問題：本地在合并消息的時候，是分段合并的，不能保證消息的連續性和唯一性。
諸如以上的幾種情況，我們首先是對客戶端的代碼做了梳理與重構。
架構如下圖所示：
5、我們的優化工作1：升級通心核心
解決問題第一步就是解決當前消息系統唯一性的問題。
我們也調研了釘釘的方案，釘釘是服務端全局維護消息的唯一ID，考慮到閑魚即時消息系統的歷史包袱，我們這邊采用UUID作為消息的唯一ID，這樣就可以在消息鏈路埋點以及去重上得到很大的改善。
5.1 解決消息唯一性
在新版本的APP上面，客戶端會生成一個uuid，對于老版本無法生成的情況，服務端也會補充上相關信息。
消息的ID類似于 a1a3ffa118834033ac7a8b8353b7c6d9，客戶端在接收到消息后，會先根據MessageID來去重，然后基于Timestamp排序就可以了，雖然客戶端的時間可能不一樣，但是重復的概率還是比較小。
以iOS端為例，代碼大致如下：
- (void)combileMessages:(NSArray<PMessage*>*)messages {
...
// 1. 根據消息MessageId進行去重
NSMutableDictionary *messageMaps = [self containerMessageMap];
for (PMessage *message in msgs) {
[messageMaps setObject:message forKey:message.messageId];
}
// 2. 消息合并后排序
NSMutableArray *tempMsgs = [NSMutableArray array];
[tempMsgs addObjectsFromArray:messageMaps.allValues];
[tempMsgs sortUsingComparator:^NSComparisonResult(PMessage * _Nonnull obj1, PMessage * _Nonnull obj2) {
// 根據消息的timestamp進行排序
return obj1.timestamp > obj2.timestamp;
}];
...
}
5.2 實現消息重發、斷線重連機制
基于本文“3、行業方案”一節中的重發重連模型，我們完善了服務端的消息重發的邏輯、客戶端完善了斷線重連的邏輯。
具體措施是：
- 1）客戶端會定時檢測ACCS長連接是否聯通；
- 2）服務端會檢測設備是否在線，如果在線會推送消息，并會有超時等待；
- 3）客戶端接收到消息之后，會返回一個Ack。
5.3 優化數據同步邏輯
重發重連解決的基礎網絡層的問題，接下來就要看下業務層的問題。
現有消息系統中，很多復雜情況是通過在業務層增加兼容代碼來解決的，消息的數據同步就是一個很典型的場景。
在完善數據同步的邏輯之前，我們也調研過釘釘的一整套數據同步方案，他們主要是由服務端來保證的，背后有一個穩定的長連接保證。
釘釘的數據同步方案大致流程如下：
我們的服務端暫時還沒有這種能力，所以閑魚這邊只能從客戶端來控制數據同步的邏輯。
數據同步的方式包括：
因為涉及到的場景比較復雜，之前有個場景就是推送會觸發增量同步，如果推送過多的話，會同時觸發多次網絡請求，為了解決這個問題，我們也做了相關的推拉隊列隔離。
客戶端控制的策略就是如果在拉取的話，會先將push過來的消息加到緩存隊列里面，等拉取的結果回來，會再跟本地緩存的邏輯做合并，這樣就可以避免多次網絡請求的問題。
5.4 客戶端數據模型優化
客戶端在數據組織形式上，主要分2中：會話和消息，會話又分為：虛擬節點、會話節點和文件夾節點。
在客戶端會構建上圖一樣的樹，這棵樹主要保存的是會話顯示的相關信息，比如未讀數、紅點以及最新消息摘要，子節點更新，會順帶更新到父節點，構建樹的過程也是已讀和未讀數更新的過程。
其中比較復雜的場景是閑魚情報社，這個其實是一個文件夾節點，它包含了很多個子的會話，這就決定了他的消息排序、紅點計數以及消息摘要的更新邏輯會更復雜，服務端告知客戶端子會話的列表，然后客戶端再去拼接這些數據模型。
5.5 服務端存儲模型優化
在前述內容中，我大概講了客戶端的請求邏輯，即歷史消息會分為增量和全量域同步。
這個域其實是服務端的一層概念，本質上就是用戶消息的一層緩存，消息過來之后會暫存在緩存中，加速消息讀取。
但是這個設計也存在一個缺陷：就是域環是有長度的，最多保存256條，當用戶的消息數多于256條，只能從數據庫中讀取。
關于服務端的存儲方式，我們也調研過釘釘的方案——是寫擴散，優點就是可以很好地對每位用戶的消息做定制化，缺點就是存儲量很很大。
我們的這套解決方案，應該是介于讀擴散和寫擴散之間的一種解決方案。這個設計方式不僅使客戶端邏輯復雜，服務端的數據讀取速度也會比較慢，后續這塊也可以做優化。
6、我們的優化工作2：增加質量監控體系
在做客戶端和服務端的全鏈路改造的同時，我們也對消息線上的行為做了監控和排查的邏輯。
6.1 全鏈路排查
全鏈路排查是基于用戶的實時行為日志，客戶端的埋點通過集團實時處理引擎Flink，將數據清洗到SLS里面。
用戶的行為包括：
- 1）消息引擎對消息的處理；
- 2）用戶的點擊/訪問頁面的行為；
- 3）用戶的網絡請求。
服務端側會有一些長連接推送以及重試的日志，也會清洗到SLS，這樣就組成了從服務端到客戶端全鏈路的排查的方案。
6.2 對賬系統
當然為了驗證消息的準確性，我們還做了對賬系統：
在用戶離開會話的時候，我們會統計當前會話一定數量的消息，生成一個md5的校驗碼，上報到服務端。服務端拿到這個校驗碼之后再判定是否消息是正確的。
經過抽樣數據驗證，消息的準確性基本都在99.99%。
7、數據指標統計方法優化
我們在統計消息的關鍵指標時，遇到點問題：之前我們是用用戶埋點來統計的，發現會有3%~5%的數據差。
后來我們采用抽樣實時上報的數據來計算數據指標：
消息到達率 = 客戶端實際收到的消息量 / 客戶端應該收到的消息量
客戶端實際收到的消息的定義為“消息落庫才算是”。
該指標不區分離線在線，取用戶當日最后一次更新設備時間，理論上當天且在此時間之前下發的消息都應該收到。
經過前述優化工作，我們最新版本的消息到達率已經基本達到99.9%，從輿情上來看，反饋丟消息的也確實少了很多。
8、未來規劃
整體看來，經過一年的優化治理，我們的即時消息系統各項指標在慢慢變好。
但還是存在一些待優化的方面：
- 1）消息的安全性不足：容易被黑產利用，借助消息發送一些違規的內容；
- 2）消息的擴展性較弱：增加一些卡片或者能力就要發版，缺少了動態化和擴展的能力。
- 3）底層的伸縮性不足：現在底層協議比較難擴展，后續還是要規范一下協議。
從業務角度看，消息應該是一個橫向支撐的工具性或者平臺型的產品，且可以快速對接二方和三方的快速對接。
接下來，我們會持續關注消息相關的用戶輿情，希望閑魚即時消息系統能幫助用戶更好的完成業務交易。
附錄：更多相關文章
[1] 更多阿里巴巴的技術資源：
《阿里釘釘技術分享：企業級IM王者——釘釘在后端架構上的過人之處》
《現代IM系統中聊天消息的同步和存儲方案探討》
《阿里技術分享：深度揭秘阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
《釘釘——基于IM技術的新一代企業OA平臺的技術挑戰(視頻+PPT) [附件下載]》
《阿里技術結晶：《阿里巴巴Java開發手冊(規約)-華山版》[附件下載]》
《重磅發布：《阿里巴巴Android開發手冊(規約)》[附件下載]》
《作者談《阿里巴巴Java開發手冊(規約)》背后的故事》
《《阿里巴巴Android開發手冊(規約)》背后的故事》
《干了這碗雞湯：從理發店小弟到阿里P10技術大牛》
《揭秘阿里、騰訊、華為、百度的職級和薪酬體系》
《淘寶技術分享：手淘億級移動端接入層網關的技術演進之路》
《難得干貨，揭秘支付寶的2維碼掃碼技術優化實踐之路》
《淘寶直播技術干貨：高清、低延時的實時視頻直播技術解密》
《阿里技術分享：電商IM消息平臺，在群聊、直播場景下的技術實踐》
《阿里技術分享：閑魚IM基于Flutter的移動端跨端改造實踐》
《阿里IM技術分享(三)：閑魚億級IM消息系統的架構演進之路》
《阿里IM技術分享(四)：閑魚億級IM消息系統的可靠投遞優化實踐》
[2] 有關IM架構設計的文章：
《淺談IM系統的架構設計》
《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《一套原創分布式即時通訊(IM)系統理論架構方案》
《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》
《蘑菇街即時通訊/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《移動端IM中大規模群消息的推送如何保證效率、實時性？》
《現代IM系統中聊天消息的同步和存儲方案探討》
《微信朋友圈千億訪問量背后的技術挑戰和實踐總結》
《子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐》
《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》
《從游擊隊到正規軍(一)：馬蜂窩旅游網的IM系統架構演進之路》
《從游擊隊到正規軍(二)：馬蜂窩旅游網的IM客戶端架構演進和實踐總結》
《從游擊隊到正規軍(三)：基于Go的馬蜂窩旅游網分布式IM系統技術實踐》
《瓜子IM智能客服系統的數據架構設計（整理自現場演講，有配套PPT）》
《IM開發基礎知識補課(九)：想開發IM集群？先搞懂什么是RPC！》
《阿里技術分享：電商IM消息平臺，在群聊、直播場景下的技術實踐》
《一套億級用戶的IM架構技術干貨(上篇)：整體架構、服務拆分等》
《一套億級用戶的IM架構技術干貨(下篇)：可靠性、有序性、弱網優化等》
《從新手到專家：如何設計一套億級消息量的分布式IM系統》
《企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等》
《融云技術分享：全面揭秘億級IM消息的可靠投遞機制》
《IM開發技術學習：揭秘微信朋友圈這種信息推流背后的系統設計》
《阿里IM技術分享(三)：閑魚億級IM消息系統的架構演進之路》
>> 更多同類文章 ……
本文已同步發布于“即時通訊技術圈”公眾號。
同步發布鏈接是：http://www.52im.net/thread-3706-1-1.html