作者：閑魚技術——今朝 、有攸
引言
閑魚消息系統經過幾代開發的建設，目前穩定的支撐億級消息體量。在消息系統建設過程中，我們經曆了從簡單到複雜，從困擾到破局，每一次的技術改變都是為了更好的解決當下業務面臨的問題。“憶昔午橋橋上飲，坐中多是豪英“，此文記錄閑魚消息系統技術變遷，以期在此基礎上汲取更多經驗。
閑魚消息1.0:業務初創期，最小化可用
背景：14年啟動閑置交易獨立APP “閑魚”，一期建構完成APP主鍊路，包含商品釋出→搜尋→商品詳情→IM會話→交易。作為初創app，業務需盡快上線驗證效果，技術建設上需要完成閑魚消息從無到有的系統搭建。
作為即時通訊系統，最小化能力包含
- 消息存儲：會話、摘要、消息
- 消息同步：推、拉
- 消息通道：長連接配接、廠商推送
與一般IM會話模型不同的是，閑魚會話以商品為主體，人＋人+商品為要素建構會話，因會話模型的差異，淘系已有的消息系統，短期内無法滿足業務需求，而閑魚完全自建消息系統耗時巨大。為了保障業務高效上線，技術選型上最大化複用已有系統能力，避免重複造輪子。
是以，
- 資料模型與底層存儲依賴淘系私信體系進行建設；
- 消息資料擷取上，用戶端全量從服務端拉取消息資料
- 通訊協定使用來往SDK及mtop
總體架構如下圖，以此模式完成快速傳遞保障了業務最小化可用
閑魚消息2.0：使用者量高增速，重建閑魚消息系統
背景： 閑魚使用者量快速突破100W，消息服務調用量暴漲。常态性的，使用者回報消息資料擷取卡頓、白屏，大量的push發送下，系統告警頻發。
造成這些問題的原因：消息1.0 模式下，擷取消息資料全量拉模式，用戶端純UI不做資料存儲
- 當使用者需要檢視消息資料時，資料拉取成功與否取決于網絡、資料通路速度，偶發性的造成卡頓、白屏
-
中心化的資料存儲，讀遠大于寫，高并發下，服務端負載過大
比如1W個使用者同時線上聊天，按照目前架構并發拉取全量消息，估算5Wqps. 不妨假設，同時線上聊天使用者數10W時，對服務端壓力可想而知
基于上述問題，我們決定重建消息系統，以應對未來更大的使用者增量。回歸到IM系統的核心功能
消息存儲模型：
會話模型：由owner、itemid、user、sessionType 來辨別唯一會話，增加擴充屬性支援個性化
摘要模型：作為使用者會話視圖，同一會話的不同使用者可個性化呈現，由userid、sid辨別唯一摘要
消息模型：由sender、消息内容、消息版本、sid組成。sid+消息版本唯一确定一條消息
指令模型：是一種雙端約定，由服務端下發，用戶端執行的指令集。如免打擾指令、删除指令等
消息通道：
線上通道：使用淘寶無線ACCS長連接配接提供的全雙工、低延時、高安全的通道服務。
離線通道：使用淘寶消息推送平台AGOO. 其屏蔽了各主流廠商對接的複雜度，直接對業務系統提供服務
消息同步模型：
1.用戶端建立資料庫，存儲消息資料
當消息資料存儲在本地裝置上，消息同步從全量拉取優化為全量+增量同步結合的模式。 增量同步：用戶端存儲消息位點資訊，通過與服務端最新位點比較，僅同步增量消息；全量同步：當使用者解除安裝重裝或位點gap過大時，用戶端全量拉取曆史消息資料，進行端上資料重建 2.服務端建設個人消息域環(收件箱模型)，以和用戶端進行增量資料同步。同時，消息1.0版本存在的讀多寫少的問題，通過個人域環的寫擴散來平衡讀寫壓力
下圖為一條消息從發送到接收的過程以及服務端和用戶端的執行流程
如圖所示，假設Ua給Ub發送一條消息，消息寫擴散至Ua和Ub的各自的域環中。
1.當用戶端online時，接收到推送的消息位點=目前端上域版本+1，本地消息資料庫merge即可
2.當用戶端offline時，僅進行離線推送通知，當使用者重新上線時，進行資料同步，由服務端判斷觸發增量同步還是全量同步
如果域環版本內插補點小于閥值，增量同步後，進行本地消息資料庫merge
當域環版本內插補點大于閥值，進行全量消息拉取，做端上資料重建
整個同步邏輯基于閑魚的消息域環，域環可以看作是有着固定容量的使用者消息收件箱，給一個使用者發送的所有消息都會同步到他的域環中。
域環存儲：域環需要支援高并發資料讀寫，使用阿裡分布式KV存儲系統tair來實作
域環容量：為減少全量消息同步，以使用者下次進入閑魚需要同步的平均消息量來規劃個人域環容量。同時利用FIFO循環覆寫曆史資料
域環版本：使用者目前消息位點，在消息進入個人域環時通過tair的counter實作域環版本嚴格連續遞增，用于全量、增量同步判斷
上述建設完成後，閑魚具備了自己獨立的消息系統，當下遇到的問題得到了緩解，使用者體驗度有大幅提升。
閑魚消息3.0：業務快速發展下，系統穩定性保障
背景： 随着閑魚業務生态的豐富，IM會話與消息内容類型不斷擴充，同時在DAU的快速增長下，使用者回報消息收不到、消息延遲等輿情問題日漸突出。
問題分析:
1.閑魚app程序無有效保活機制，app退到背景後程序很快就會被系統挂起，導緻長連接配接中斷。此時消息推送走廠商通道，而廠商通道的實時性較差，且對消息推送的優先級設定有差異，進而造成使用者感覺消息延遲
2.accs線上消息推送時，平均延時較短，但存在假連情況，而且目前的消息推送鍊路無ack機制，造成服務端以為消息發出去了但實際上用戶端并沒有收到，使用者下次打開app後才能看到消息，使用者感覺消息延遲。造成假連接配接的原因：使用者退到背景，accs長連中斷，但是裝置狀态更新有延時。
3.目前消息同步的推模式(accs push)、拉模式(mtop)，用戶端未做隔離，異步進行處理，導緻在某些極端情況下消息資料庫處理異常，引發消息丢失。比如某使用者上線後連續收到多條消息，其中一條觸發域黑洞，在進行消息同步端上資料重建時，小機率處理出錯。
4.大部分線上消息問題發現靠輿情回報，如消息錯亂，出問題後系統無感覺、無補救措施且排查困難，僅能跟随版本做修複
5.業務不斷豐富，孵化出基于消息系統的服務号及小程式内容營銷、消息群組等，各類消息發送鍊路共用域環與資料存儲，造成穩定性問題。如個人域環的消息包括IM聊天和營銷消息，IM聊天由使用者觸發，需要保證強到達；而營銷消息一般是由系統通過班車等方式批量發送，消息量級大，tps高，影響IM服務穩定性
基于上述分析，我們進行專項解決：
消息重發與推拉隔離
ACK: 保障消息及時到達。服務端下行accs消息時，将消息加入重試隊列并延遲重試，用戶端在收到accs消息并處理成功後，給服務端回一個ack，服務端收到ack後更新消息到達狀态，并終止重試，以此避免裝置假連或網絡不穩定的情況。
重發：根據延遲重發政策決定何時重發消息，保障消息确定性到達。自适應延遲重發政策是指新消息先通過4次固定N秒的短延遲來探測裝置的網絡狀況，然後根據網絡狀況來遞增固定步長M的延遲政策，這種政策可以保障在最短的時間内，使用最少的重發次數将消息投遞成功。
消息隊列：端上引入消息隊列，按順序處理消息，保證消息處理的準确性。同時進行推拉隔離，保障隊列有序消費，解決了複雜狀況下并發處理消息資料合并出錯的問題。
資料存儲拆分
閑魚每天發送的消息中有一半以上是營銷消息，營銷消息的發送具有明顯的波峰波谷流量，高峰期會導緻消息資料庫抖動，影響IM消息。對消息、摘要、域環存儲做業務隔離，以适應不同業務場景對穩定性不同的要求。
- IM消息需要極高的穩定性保證，其消息及摘要繼續使用mysql存儲
- 營銷消息存儲周期短，穩定性要求低于IM，采用Lindorm存儲。Lindorm是一種多模型的雲原生資料庫服務，具有成本低、自定義TTL、容量橫向擴充等優勢
- 域環做執行個體級别隔離，保證IM域環的容量不會被其他消息占用，進而影響到消息同步
線上問題發現與恢複
保障穩定性的關鍵要素是做好各種核心名額的監控，而監控首先要有資料來源，對服務端+用戶端的關鍵鍊路節點埋點，基于集團UT、SLS，通過blink進行實時清洗、計算，最終形成統一規範的日志資料落至SLS，以供實時監控及鍊路排查。
消息系統的核心目标是保障使用者消息發的出、收得到且及時收到，是以我們通過計算發送成功率、到達率、消息延遲來監控系統的穩定性。此外，為了解決使用者輿情排查困難的問題
- 我們設計了一套指令集，通過約定指令協定，服務端向指定使用者下發指令，用戶端執行對應指令進行異常資料上報，提高排查效率
- 擴充了強制全量同步、資料校正等指令，定向修複使用者消息資料問題，相較以往出現嚴重bug隻能讓使用者解除安裝重裝解決，這種方式顯然對使用者是更友好的
經過一系列專項治理，技術類輿情下降50%，從0到1建設了消息穩定性體系，使用者體驗進一步提升。
最後：龐大的使用者體量下，追求極緻的NPS
閑魚作為電商交易APP， 其中IM是交易的前置鍊路，IM的産品體驗極大影響使用者交易效率
前段時間進行使用者調研，從閑魚IM NPS低于預期(NPS是使用者忠誠度衡量名額 = 推薦者%-貶損者%)，從使用者回報來看：
- 部分使用者對産品功能有較強烈的訴求，諸如消息搜尋、分組等
- 大部分使用者對發送消息過程中的違規問題難以了解
- 仍有較多輿情回報消息收不到或延遲
映射到目前閑魚的消息系統上，我們的系統架構依然有很多需要持續改進的地方。典型的如同步協定備援，在需求疊代過程中容易引發問題、有效保活機制的缺失對消息即時送達的影響、小衆機型離線消息收不到、多年的資料積累線上庫臃腫等問題，影響着閑魚業務疊代速度與NPS。将提升NPS作為核心目标，閑魚消息4.0進行時......