本文由阿里閒魚技術團隊書閒分享，原題“如何有效縮短閒魚消息處理時長”，有修訂和改動。

1、引言

閒魚技術團隊圍繞IM這個技術範疇，已經分享了好幾篇實踐性總結文章，本篇將要分享的是閒魚IM系統中在線和離線聊天消息數據的同步機制上所遇到的一些問題，以及實踐性的解決方案。

2、系列文章

本文是系列文章的第7篇，總目錄如下：

3、問題背景

隨着用戶數的快速增長，閒魚IM系統也迎來了前所未有的挑戰。

歷經多年的業務迭代，客戶端側IM的代碼已經因爲多年的迭代層次結構不足夠清晰，之前一些隱藏起來的聊天數據同步問題，也隨着用戶數的增大而被放大。

這裏面的具體流程在於：後臺需要同步到用戶端側的數據包，後臺會根據數據包的業務類型劃分成不同的數據域，數據包在對應域裏面存在唯一且連續的編號，每一個數據包發送到端側並且被成功消費後，端側會記錄當前每一個數據域已經同步過的版本編號，下一次數據同步就以本地數據域的編號開始，不斷的同步到客戶端。

當然用戶不會一直在線等待消息，所以之前端側採用了推拉結合的方式保證數據的同步。

具體就是：

1）客戶端在線時：使用ACCS實時的將最新的數據內容推送到客戶端（ACCS是淘寶無線向開發者提供全雙工、低延時、高安全的通道服務）；
2）客戶端從離線狀態啓動後：根據本地的數據域編號，拉取不在線時候的數據差；
3）當數據獲取出現黑洞時：觸發數據同步拉取（“黑洞”即指數據包Version不連續的狀態）。

4、問題分析

當前的聊天數據同步策略確實是可以基本保障IM的數據同步的，但是也伴隨着一些隱含的問題。

這些隱含的問題主要有：

1）短時間密集數據推送時，會快速的觸發多次數據域同步。域同步回來的數據如果存在問題，又會觸發新一輪的同步，造成網絡資源的浪費。冗餘數據包/無效的數據內容會佔用有效內容的處理資源，又對CPU和內存資源造成浪費；
2）數據域中的數據包客戶端是否正常消費，服務端側無感知，只能被動地根據當前數據域信息返回數據；
3）數據收取/消息數據體解析/存儲落庫邏輯拆分不夠清晰，無法針對性的對某一層的代碼拆分替換進行ABTest。

針對上述問題，我們對閒魚IM進行了分層改造——即抽離數據同步層。這樣優化，除了希望以後這個數據的同步內容可以用在IM之外，也希望隨着穩定性的增加，賦能其他的業務場景。

接下來的內容，我們重點來看下解決客戶端側閒魚IM聊天數據同步問題的一些實踐思路。

5、優化思路

5.1 分層拆分

對於服務端來說：業務側產出數據包後，會拼接上當前的數據域信息，然後通過數據同步層將數據推送到端側。

對於客戶端來說：接收到數據包後，會根據當前的數據域信息，來確定需要消費數據包的業務方，確保數據包在數據域內完整連續後，將數據體脫殼後交於業務側消費，並且應答消費的狀況。

數據同步層的抽取：把數據同步中的加殼、脫殼、校驗、重試流程封裝到一起，可以讓上層業務只需要關心自己需要監聽的數據域信息，然後當這些數據域更新數據的時候，可以獲取到這些數據進行消費，而不再需要關心數據包是否完整。

這樣做的話：

1）業務側只需要關心業務側對接的協議；
2）數據側只需要關心數據側包裝的協議；
3）網絡層負責真實的數據傳輸。

整體的架構原理如下：

總結一下就是：

1）對齊數據層數據傳輸協議、描述當前數據包體數據域信息；
2）將消息的處理/合併/落庫抽離成數據消費者；
3）上下樓依賴抽象化，去除對於具體實現的依賴。

5.2 數據層結構模型

基於對於數據模型剝離和對當下遇見問題的解決方案規整，將數據同步層拆分爲下圖這樣的架構。

具體的實施思路就是：

1）App啓動時建立ACCS長鏈接服務，保證推推送信道鏈接，並且根據當前本地數據域信息觸發一次數據拉取；
2）數據消費者註冊消費者信息和需要監聽的數據域信息，這裏是一對多的關係；
3）新的數據抵達端側後，將數據包放到指定的數據域的緩衝池，批量數據歸納結束後，重新出發數據的讀取；
4）根據當前數據域優先級彈出最高優的數據包，判斷數據域版本是否符合消費者要求，符合則將數據包脫殼後丟給消費者消費，不符合則根據上一次正確的數據包的域信息觸發增量的數據域同步拉取；
5）觸發數據域同步拉取時，block數據讀取，此時通過ACCS觸達的數據依舊會在繼續歸納到指定的數據域隊列中，等待數據域同步拉取結果，將數據包進行排序、去重，合併到對應的數據域隊列中。然後重新激活數據讀取；
6）數據包體被消費者正確消費後，更新域信息並且通過上行信道告知服務端已經正確處理的數據域信息。

* 數據域同步協議：

Region中攜帶的數據不必過多，但需將數據包的內容描述清楚，具體是：

1）目標用戶的ID，用以確定目標數據包是否正確；
2）數據域ID和優先級信息；
3）當前數據包的域優先級版本。

* 排序策略：

針對於域數據歸納，無論是在寫入數據的時候進行排序還是在讀取的時候進行查找都需要進行一次排序的操作，時間複雜度最優也是O(logn)級別的。

在實際coding中發現由於在一個數據域裏面，數據包的Version信息是連續唯一併且不存在斷層的，上一個穩定消費的數據體的Version信息自增就是下一個數據包的Version，所以這裏採用了以Versio爲主鍵的Map存儲，既降低了時間複雜度，也使得唯一標識的數據包後抵達端側的包內容可以覆蓋之前的包內容。