簡介： 記錄這一年閒魚消息的優化之路
1. 背景
在2020年年初的時候接手了閒魚的消息，當時的消息存在各種問題，網上的輿情也是接連不斷：“閒魚消息經常丟失”、“消息用戶頭像亂了”、“訂單狀態不對”（相信現在看文章的你還在吐槽閒魚的消息）。所以閒魚的穩定性是一個亟待解決的問題，我們調研了集團的一些解決方案，例如釘釘的IMPass。直接遷移的成本和風險都是比較大，包括服務端數據需要雙寫、新老版本兼容等。
那基於閒魚現有的消息架構和體系，如何來保證它的穩定性？治理應該從哪裏開始？現在閒魚的穩定性是什麼樣的？如何衡量穩定性？希望這篇文章，能讓大家看到一個不一樣的閒魚消息。
2. 行業方案
消息的投遞鏈路大致分爲三步：發送者發送，服務端接收然後落庫，服務端通知接收端。特別是移動端的網絡環境比較複雜，可能你發着消息，網絡突然斷掉了；可能消息正在發送中，網絡突然好了，需要重發。
在如此複雜的網絡環境下，是如何穩定可靠的進行消息投遞的？對發送者來說，它不知道消息是否有送達，要想做到確定送達，就需要加一個響應機制，類似下面的響應邏輯：
- 發送者發送了一條消息“Hello”，進入等待狀態。
- 接收者收到這條消息“Hello”，然後告訴發送者說我已經收到這條消息了的確認信息。
- 發送者接收到確認信息後，這個流程就算完成了，否則會重試。
上面流程看似簡單，關鍵是中間有個服務端轉發過程，問題就在於誰來回這個確認信息，什麼時候回這個確認信息。網上查到比較多的是如下一個必達模型，如下圖所示：
[發送流程]
-
A向IM-server發送一個消息請求包，即msg:R1 -
IM-server在成功處理後，回覆A一個消息響應包，即msg:A1 - 如果此時
B在線，則IM-server主動向B發送一個消息通知包，即msg:N1（當然，如果B不在線，則消息會存儲離線）
[接收流程]
-
B向IM-server發送一個ack請求包，即ack:R2 -
IM-server在成功處理後，回覆B一個ack響應包，即ack:A2 - 則
IM-server主動向A發送一個ack通知包，即ack:N2
一個可信的消息送達系統就是靠的6條報文來保證的，有這個投遞模型來決定消息的必達，中間任何一個環節出錯，都可以基於這個request-ack機制來判定是否出錯並重試。看下在第4.2章中，也是參考了上面這個模型，客戶端發送的邏輯是直接基於http的所以暫時不用做重試，主要是在服務端往客戶端推送的時候，會加上重試的邏輯。
3. 閒魚消息的問題
剛接手閒魚消息，沒有穩定相關的數據，所以第一步還是要對閒魚消息做一個系統的排查，首先對消息做了全鏈路埋點。
基於消息的整個鏈路，我們梳理出來了幾個關鍵的指標：發送成功率、消息到達率、客戶端落庫率。整個數據的統計都是基於埋點來做的。在埋點的過程總，發現了一個很大的問題：閒魚的消息沒有一個全局唯一的ID，導致在全鏈路埋點的過程中，無法唯一確定這條消息的生命週期。
3.1 消息唯一性問題
之前閒魚的消息是通過3個變量來唯一確定一個消息
- SessionID: 當前會話的ID
- SeqID：用戶當前本地發送的消息序號，服務端是不關心此數據，完全是透傳
- Version：這個比較重要，是消息在當前會話中的序號，已服務端爲準，但是客戶端也會生成一個假的version
以上圖爲例，當A和B同時發送消息的時候，都會在本地生成如上幾個關鍵信息，當A發送的消息（黃色）首先到達服務端，因爲前面沒有其他version的消息，所以會將原數據返回給A，客戶端A接收到消息的時候，再跟本地的消息做合併，只會保留一條消息。同時服務端也會將此消息發送給B，因爲B本地也有一個version=1的消息，所以服務端過來的消息就會被過濾掉，這就出現消息丟失的問題。
當B發送消息到達服務端後，因爲已經有version=1的消息，所以服務端會將B的消息version遞增，此時消息的version=2。這條消息發送給A，和本地消息可以正常合併。但是當此消息返回給B的時候，和本地的消息合併，會出現2條一樣的消息，出現消息重複，這也是爲什麼閒魚之前總是出現消息丟失和消息重複最主要的原因。
3.2 消息推送邏輯問題
之前閒魚的消息的推送邏輯也存在很大的問題，發送端使用http請求，發送消息內容，基本不會出問題，問題是出現在服務端給另外一端推送的時候。如下圖所示，
服務端在給客戶端推送的時候，會先判斷此時客戶端是否在線，如果在線纔會推送，如果不在線就會推離線消息。這個做法就非常的簡單粗暴。長連接的狀態如果不穩定，導致客戶端真實狀態和服務端的存儲狀態不一致，就導致消息不會推送到端上。
3.3 客戶端邏輯問題
除了以上跟服務端有關係外，還有一類問題是客戶端本身設計的問題，可以歸結爲以下幾種情況：
- 多線程問題
反饋消息列表頁面會出現佈局錯亂，本地數據還沒有完全初始化好，就開始渲染界面
- 未讀數和小紅點的計數不準確
本地的顯示數據和數據庫存儲的不一致。
- 消息合併問題
本地在合併消息的時候，是分段合併的，不能保證消息的連續性和唯一性。
諸如以上的幾種情況，我們首先是對客戶端的代碼做了梳理與重構，架構如下圖所示：
4. 我們的解法 - 引擎升級
進行治理的第一步就是，解決閒魚消息的唯一性的問題。我們也調研了釘釘的方案，釘釘是服務端全局維護消息的唯一ID，考慮到閒魚消息的歷史包袱，我們這邊採用UUID作爲消息的唯一ID，這樣就可以在消息鏈路埋點以及去重上得到很大的改善。
4.1 消息唯一性
在新版本的APP上面，客戶端會生成一個uuid，對於老版本無法生成的情況，服務端也會補充上相關信息。
消息的ID類似a1a3ffa118834033ac7a8b8353b7c6d9，客戶端在接收到消息後，會先根據MessageID來去重，然後基於Timestamp排序就可以了，雖然客戶端的時間可能不一樣，但是重複的概率還是比較小。
- (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;
}];
...
}
4.2 重發重連
基於#2中的重發重連模型，閒魚完善了服務端的重發的邏輯，客戶端完善了重連的邏輯。
- 客戶端會定時檢測ACCS長連接是否聯通
- 服務端會檢測設備是否在線，如果在線會推送消息，並會有超時等待
- 客戶端接收到消息之後，會返回一個Ack
已經有小夥伴發表了一篇文章：《向消息延遲說bybye：閒魚消息及時到達方案（詳細）》，講解了下關於網絡不穩定給閒魚消息帶來的問題，在這裏就不多贅述了。
4.3 數據同步
重發重連是解決的基礎網絡層的問題，接下來就要看下業務層的問題，很多複雜情況是通過在業務層增加兼容代碼來解決的，閒魚消息的數據同步就是一個很典型的場景。在完善數據同步的邏輯之前，我們也調研過釘釘的一整套數據同步方案，他們主要是由服務端來保證的，背後有一個穩定的長連接保證，大致流程如下：
閒魚的服務端暫時還沒有這種能力，原因詳見4.5的服務端存儲模型。所以閒魚這邊只能從客戶端來控制數據同步的邏輯，數據同步的方式包括：拉取會話、拉取消息、推送消息等。因爲涉及到的場景比較複雜，之前有個場景就是推送會觸發增量同步，如果推送過多的話，會同時觸發多次網絡請求，爲了解決這個問題，我們也做了相關的推拉隊列隔離。
客戶端控制的策略就是如果在拉取的話，會先將push過來的消息加到緩存隊列裏面，等拉取的結果回來，會再跟本地緩存的邏輯做合併，這樣就可以避免多次網絡請求的問題。之前同事已經寫了一篇關於推拉流控制的邏輯，《如何有效縮短閒魚消息處理時長》，這裏也不過多贅述了。
4.4 客戶端模型
客戶端在數據組織形式上，主要分2中：會話和消息，會話又分爲虛擬節點、會話節點和文件夾節點。
在客戶端會構建上圖一樣的樹，這棵樹主要保存的是會話顯示的相關信息，比如未讀數、紅點以及最新消息摘要，子節點更新，會順帶更新到父節點，構建樹的過程也是已讀和未讀數更新的過程。其中比較複雜的場景是閒魚情報社，這個其實是一個文件夾節點，它包含了很多個子的會話，這就決定了他的消息排序、紅點計數以及消息摘要的更新邏輯會更復雜，服務端告知客戶端子會話的列表，然後客戶端再去拼接這些數據模型。
4.5 服務端存儲模型
在4.3中大概講了客戶端的請求邏輯，歷史消息會分爲增量和全量域同步。這個域其實是服務端的一層概念，本質上就是用戶消息的一層緩存，消息過來之後會暫存在緩存中，加速消息讀取。但是這個設計也存在一個缺陷，就是域環是有長度的，最多保存256條，當用戶的消息數多於256條，只能從數據庫中讀取。
關於服務端的存儲方式，我們也調研過釘釘的方案，是寫擴散，優點就是可以很好地對每位用戶的消息做定製化，比如釘的邏輯，缺點就是存儲量很很大。閒魚的這套解決方案，應該是介於讀擴散和寫擴散之間的一種解決方案。這個設計方式不僅使客戶端邏輯複雜，服務端的數據讀取速度也會比較慢，後續這塊也可以做優化。
5. 我們的解法 - 質量監控
在做客戶端和服務端的全鏈路改造的同時，我們也對消息線上的行爲做了監控和排查的邏輯。
5.1 全鏈路排查
全鏈路排查是基於用戶的實時行爲日誌，客戶端的埋點通過集團實時處理引擎Flink，將數據清洗到SLS裏面，用戶的行爲包括了消息引擎對消息的處理、用戶的點擊/訪問頁面的行爲、以及用戶的網絡請求。服務端測會有一些長連接推送以及重試的日誌，也會清洗到SLS，這樣就組成了從服務端到客戶端全鏈路的排查的方案，詳情請參考《消息質量平臺系列文章|全鏈路排查篇》。
5.2 對賬系統
當然爲了驗證消息的準確性，我們還做了對賬系統。
在用戶離開會話的時候，我們會統計當前會話一定數量的消息，生成一個md5的校驗碼，上報到服務端。服務端拿到這個校驗碼之後再判定是否消息是正確的，經過抽樣數據驗證，消息的準確性基本都在99.99%。
6 核心數據指標
我們在統計消息的關鍵指標的時候，遇到點問題，之前我們是用用戶埋點來統計的，發現會有3%~5%的數據差；所以後來我們採用抽樣實時上報的數據來計算數據指標。
消息到達率=客戶端實際收到的消息量/客戶端應該收到的消息量
客戶端實際收到的消息的定義爲消息落庫纔算是
該指標不區分離線在線，取用戶當日最後一次更新設備時間，理論上當天且在此時間之前下發的消息都應該收到。
最新版本的到達率已經基本達到99.9%，從輿情上來看，反饋丟消息的也確實少了很多。
7. 未來規劃
整體看來，經過一年的治理，閒魚的消息在慢慢的變好，但還是存在一些待優化的方面：
- 現在消息的安全性不足，容易被黑產利用，藉助消息發送一些違規的內容。
- 消息的擴展性較弱，增加一些卡片或者能力就要發版，缺少了動態化和擴展的能力。
- 現在底層協議比較難擴展，後續還是要規範一下協議。
- 從業務角度看，消息應該是一個橫向支撐的工具性或者平臺型的產品，規劃可以快速對接二方和三方的快速對接。
在2021年，我們會持續關注消息相關的用戶輿情，希望閒魚消息能幫助閒魚用戶更好的完成二手交易。
作者：閒魚技術——景松
本文爲阿里雲原創內容，未經允許不得轉載