但凡接手過IM系統(tǒng)的同學(xué)都繞不開“消息收發(fā)流程方案選型”這道坎。選型選得好后面開發(fā)順風(fēng)順?biāo)x型選錯了改起來就是傷筋動骨。市面上聊IM的文章很多但大多停留在“高并發(fā)IM”“消息推送”這種概念層面真正把一條消息從發(fā)送端走到接收端這個過程掰開了講清楚并且告訴你怎么在不同場景下做取舍的內(nèi)容其實并不多。這篇文章我想從我自己實際帶團隊做IM項目的經(jīng)驗出發(fā)把消息收發(fā)流程里最關(guān)鍵的幾個決策點、技術(shù)細節(jié)和踩坑記錄完整講一遍。無論你是在調(diào)研自研IM、準(zhǔn)備集成第三方SDK還是純粹想弄清楚網(wǎng)頁版IM這種成熟產(chǎn)品背后的設(shè)計邏輯這篇內(nèi)容都能給你一個相對清晰的選型參考。我盡量不堆術(shù)語遇到繞不開的概念會用生活里的類比去解釋也會把一些參數(shù)和配置直接列出來方便你照著評估。1. 消息收發(fā)流程的整體設(shè)計與方案選型思路1.1 為什么先要捋清楚消息收發(fā)流程再做選型我見過不少團隊上來就糾結(jié)用哪個框架、哪個中間件、哪個云廠商結(jié)果聊了半天發(fā)現(xiàn)連自己要做的是“單聊為主”還是“群聊為主”都沒定下來。說實話IM系統(tǒng)最核心的復(fù)雜度根本不在于某個具體組件而在于消息從A端發(fā)出最終如何可靠、有序、低延遲地到達B端這條鏈路上的每個環(huán)節(jié)。消息收發(fā)流程往大了說無非就是發(fā)送端→接入層→消息處理服務(wù)→存儲層→推送通道→接收端。但這條鏈路里的任何一環(huán)出了問題表現(xiàn)到用戶側(cè)就是“消息發(fā)了沒收到”“消息重復(fù)了”“消息亂序了”“離線消息丟了”這些非常傷體驗的問題。方案選型本質(zhì)上是在為這條鏈路里每個環(huán)節(jié)選擇最合適的處理方式而不是單純挑一個“聽起來很厲害”的技術(shù)棧。所以我建議所有剛啟動IM項目的團隊第一件事不是寫代碼而是把下面這份問題清單逐項過一遍用戶規(guī)模預(yù)期是多少是幾百人的內(nèi)部工具還是百萬日活的公網(wǎng)產(chǎn)品消息是單聊為主還是群聊為主群規(guī)模上限是多少人在線率和離線率大概什么比例有多少消息需要走離線存儲對消息丟失的容忍度有多高哪些消息絕對不能丟對消息順序的約束是全局嚴(yán)格有序還是只需要會話內(nèi)有序團隊有多少人可以投入開發(fā)有充裕的時間做底層自研嗎是否需要多端同步Web、App、桌面端這些問題的答案會直接決定你在“自研IM”和“接入第三方”之間的傾向也會決定你在長連接方案、消息存儲方案、離線消息處理方案上的具體取舍。1.2 一條消息從發(fā)出到被看到的完整鏈路把IM的消息收發(fā)流程簡化以后幾乎所有方案都逃不開下面這條鏈路發(fā)送端→接入網(wǎng)關(guān)→消息處理服務(wù)→消息存儲→推送/拉取模塊→接收端發(fā)送端用戶敲完消息點擊發(fā)送客戶端先把消息寫入本地數(shù)據(jù)庫同時生成一個本地的臨時消息ID通常叫clientMsgId然后通過長連接WebSocket或自研TCP協(xié)議把消息上行到服務(wù)端。接入網(wǎng)關(guān)負責(zé)維持海量客戶端的連接處理連接鑒權(quán)、心跳、斷線重連、流量控制。網(wǎng)關(guān)一般不處理業(yè)務(wù)邏輯只做協(xié)議解析和轉(zhuǎn)發(fā)這樣才能做到無狀態(tài)水平擴展。消息處理服務(wù)拿到上行消息后先校驗發(fā)送者權(quán)限、做內(nèi)容安全過濾然后生成服務(wù)端消息ID寫入存儲再決定走“實時推送”還是“離線存儲”的分支。消息存儲一般分兩部分一份是發(fā)送者和接收者的會話消息記錄用于歷史消息拉取一份是在線/離線狀態(tài)索引用于判斷消息要不要走推送。推送/拉取模塊接收端在線時通過長連接實時下行推送消息接收端離線時把消息存入離線消息表等接收端下次上線時通過增量拉取同步下來?？吹竭@里你應(yīng)該能理解為什么“方案選型”會被單獨拿出來當(dāng)成一個話題來聊。因為這條鏈路上每一個環(huán)節(jié)都有多種技術(shù)實現(xiàn)路徑不同路徑組合起來就是一套完全不同的系統(tǒng)形態(tài)。比如接入網(wǎng)關(guān)用Netty手寫長連接還是直接用WebSocket網(wǎng)關(guān)組件消息存儲用MySQL還是NoSQL離線消息用推拉結(jié)合還是純拉取群聊用寫擴散還是讀擴散——這些都是選型點。1.3 方案選型的三個關(guān)鍵分流點在線/離線、單聊/群聊、可靠性等級在我做過的IM項目里有三個分流點決定了80%的技術(shù)選型走向建議你在選型前先把這三個問題定下來。第一個分流點收到消息時接收方在線還是離線。在線和離線的處理邏輯完全不同。在線用戶適合“推送優(yōu)先”服務(wù)端直接把消息通過長連接懟給客戶端客戶端收到后回ACK鏈路短、時效性好。離線用戶則必須把消息落庫等用戶上線時再拉取。如果你的產(chǎn)品是典型的“在線協(xié)同工具”在線率高那你可以把重心放在長連接推送的穩(wěn)定性和可靠性上如果你的產(chǎn)品像郵件一樣“離線為主”那消息存儲和拉取策略反而更重要。第二個分流點消息是單聊還是群聊群聊規(guī)模上限是多少。單聊消息的處理很簡單一條消息只涉及兩個用戶寫一份存儲、推送一次就夠了。但群聊尤其是人數(shù)在幾百上千的千人大群處理邏輯會完全不一樣。這里面有一個經(jīng)典的“寫擴散”和“讀擴散”之爭后面我會單獨展開。選型時一定要明確群的上限規(guī)模因為它直接決定了你消息表的存儲模型和推送扇出量。第三個分流點對可靠性和時序的要求等級。IM和日志系統(tǒng)不太一樣它對消息的可靠性要求很高。我不能接受“這條消息丟了算了”這種設(shè)計思路因為用戶聊天記錄丟了產(chǎn)品口碑直接崩塌。但可靠性也有分級私聊消息必須零丟失、強順序群聊的普通消息可以允許輕微的延遲抖動但也不能丟像系統(tǒng)通知這類消息偶爾重發(fā)一次用戶也不會太在意。不同可靠性等級會直接影響消息確認ACK、重試、冪等機制的設(shè)計復(fù)雜度所以這也是選型前必須想清楚的事。2. 消息收發(fā)流程中的核心細節(jié)與關(guān)鍵技術(shù)點2.1 消息模型設(shè)計消息ID、時序與去重消息模型是整個IM的“地基”地基沒打牢后面整個流程都會受影響。我在項目里踩過最典型的坑就是把消息ID設(shè)計和業(yè)務(wù)需求割裂開導(dǎo)致排障時非常痛苦。一套合理的消息模型通常要包含幾個關(guān)鍵字段msg_id服務(wù)端生成的全局限一消息ID用于消息在整個系統(tǒng)中的唯一標(biāo)識。client_msg_id客戶端生成的消息ID一般用UUID用于客戶端冪等去重。session_id會話ID標(biāo)識這條消息屬于哪個單聊或群聊會話。sender_id/receiver_id發(fā)送者與接收者標(biāo)識。msg_type文本、圖片、語音、文件、系統(tǒng)消息等。content消息體內(nèi)容。status消息狀態(tài)如正常、撤回、被刪除。send_time/server_time客戶端發(fā)送時間和服務(wù)端接收時間。消息ID的生成方案我建議用Snowflake算法或者改造版的分段發(fā)號器。Snowflake的核心思想是用“時間戳機器ID序列號”拼出一個64位的整數(shù)ID全局趨勢遞增且不依賴中心化數(shù)據(jù)庫非常適合IM這種需要高并發(fā)生成分布式ID的場景。在我實際項目里消息ID生成還承擔(dān)了一個非常重要的職責(zé)作為消息排序的依據(jù)。所以服務(wù)端生成消息ID時必須保證同一個會話內(nèi)的消息ID順序與用戶發(fā)送順序一致。如果我們用Snowflake就要注意一個細節(jié)在同一毫秒內(nèi)序列號是遞增的能滿足同一發(fā)送端的順序但不同發(fā)送者在同一毫秒發(fā)到不同接入網(wǎng)關(guān)時后到達的消息可能拿到更小的ID導(dǎo)致群聊消息亂序。這個問題可以通過在消息處理服務(wù)里引入會話級串行化來解決后面我會講到。2.2 在線通道長連接推送與消息確認在線消息的核心通道是長連接?，F(xiàn)在Web端的主流方案就是WebSocketApp端一般用自研的TCP私有協(xié)議或者直接在TCP之上跑WebSocket協(xié)議。選型時不用過度糾結(jié)協(xié)議本身的優(yōu)劣更重要的是想清楚長連接上要承載哪些機制。長連接上必須承載的幾件事心跳機制客戶端和服務(wù)端需要定時互發(fā)心跳包保證連接不被中間網(wǎng)絡(luò)設(shè)備斷開同時讓服務(wù)端能感知客戶端是否還在線。心跳間隔一般建議15秒到30秒之間太頻繁耗電耗流量太稀疏又會導(dǎo)致服務(wù)端釋放連接不及時。上行消息客戶端發(fā)送消息時沿長連接發(fā)一個上行包服務(wù)端處理后返回一個“收到確認”。下行推送服務(wù)端往接收端下行推送消息時需要攜帶服務(wù)端消息ID接收端成功落庫后返回ACK。推送回執(zhí)接收端對下行的每一條消息都需要回ACK服務(wù)端收到ACK后這條消息才算真正投遞成功。這就有意思了。很多人以為“服務(wù)端把消息發(fā)出去了”就是投遞成功實際上服務(wù)端必須等接收端回ACK后才能確認。在我?guī)ы椖繒r我會明確告訴團隊成員ACK是消息可靠性的基石沒有ACK機制的消息推送本質(zhì)上就是發(fā)完不管的UDP。這也是為什么在線消息的流程總是比想象中要復(fù)雜一點——一條消息要先經(jīng)過“上行確認”再經(jīng)過“下行確認”兩次確認缺一不可。2.3 離線消息如何“不丟不重不亂”離線消息的處理邏輯核心就一句話把該存的消息存下來等用戶上線時再拉給TA。但這句話落地沒那么簡單。離線消息通常按“用戶維度”存儲。比如A給B發(fā)了一條消息B離線了服務(wù)端會往B的離線消息表里插入一條記錄。B上線時客戶端會帶著自己本地最新的消息ID增量拉取服務(wù)端把B離線期間積累的所有消息按時間順序吐給B。這就是“離線拉取”模型。實現(xiàn)“不丟不重不亂”需要三塊配合不丟離線消息必須持久化到可靠存儲不能只放內(nèi)存?？梢允褂肕ySQL或者Redis落庫雙寫但關(guān)鍵點是消息一旦確認寫入離線存儲就要考慮是否需要補償機制防止寫入失敗。不重客戶端拉取離線消息時如果網(wǎng)絡(luò)超時重試了一次可能同一批消息被拉了兩遍。解決方法是客戶端本地維護一個last_pulled_msg_id用冪等方式處理重復(fù)消息——本地收到了重復(fù)的msg_id直接跳過。不亂離線消息拉取必須按消息ID嚴(yán)格排序這里又回到消息ID設(shè)計的問題上。如果消息ID不是趨勢遞增的離線拉取排序就會很頭疼。離線消息還有一個細節(jié)容易被忽略離線消息的保留期。有些IM產(chǎn)品只保留最近30天的離線消息超過30天直接丟棄讓用戶登錄后從云端歷史消息里拉取。這種策略可以在不犧牲體驗的前提下控制離線表的膨脹我覺得非常實用。2.4 群聊消息的寫擴散與讀擴散之爭群聊是IM里最能體現(xiàn)技術(shù)深度的地方尤其當(dāng)群人數(shù)上千以后消息收發(fā)的流程設(shè)計會直接決定系統(tǒng)能不能撐得住。群聊有兩種經(jīng)典的消息分發(fā)模型寫擴散發(fā)送時擴散一條群消息發(fā)到服務(wù)端后服務(wù)端把這條消息復(fù)制N份分別寫入群里每個成員的收件箱。好處是接收端拉取時邏輯簡單查詢效率高壞處是群越大寫入放大越恐怖。一個1000人的群一條消息要寫1000份如果一個群很活躍存儲量和寫入壓力會直線上升。讀擴散接收時擴散群消息只存儲一份掛在群會話下。群成員上線拉消息時再去群會話里同步屬于自己那條時間線之后的消息。好處是寫入量小群里幾千人大幾百人緩存無壓力壞處是接收端邏輯復(fù)雜需要知道“上次同步到哪了”而且全量拉取場景比如新用戶進群可能出現(xiàn)性能瓶頸。在實際選型時我一般建議這樣權(quán)衡群人數(shù) ≤ 200可以直接考慮寫擴散因為實現(xiàn)和排查最簡單用戶體驗好。群人數(shù) 200 ~ 2000寫擴散容易放大寫壓力但也不是不能用關(guān)鍵看群的活躍度。可以在寫擴散基礎(chǔ)上做“活躍成員才寫收件箱非活躍成員讀擴散”的混合模式。群人數(shù) 2000建議認真考慮讀擴散且配合Redis緩存群時間線盡量讓拉取命中緩存而不是打存儲。這里我想到一個生活化的類比。寫擴散相當(dāng)于你發(fā)一條微信到群里群主把消息挨個私發(fā)給每個人確保大家都能收到讀擴散相當(dāng)于你發(fā)一條公告到公告欄誰想看誰就走到公告欄前自己看。前者的體驗好但跑腿多后者的跑腿少但對看公告的人有要求。2.5 消息可靠性ACK、重試與冪等的組合拳聊透了在線推送和離線存儲可以進入消息可靠性這個話題了。我在給團隊做方案評審時經(jīng)常掛在嘴邊的一句話是消息不可靠的根源往往不是某一個環(huán)節(jié)掛了而是各個環(huán)節(jié)之間缺少配合。一條消息從發(fā)送端到接收端可能在任何一環(huán)丟失?？蛻舳松闲袝r網(wǎng)絡(luò)斷了服務(wù)端處理時宕機了推送時連接斷了接收端回ACK時原連接斷了。每一環(huán)都可能出問題所以可靠性不是靠某一個“保險”就能保證的必須靠ACK、重試、冪等的組合拳上行階段客戶端發(fā)消息后如果一段時間內(nèi)沒收到服務(wù)端的確認就自動重發(fā)但重發(fā)時要帶上相同的client_msg_id這樣服務(wù)端能識別出“這條消息我處理過了”直接返回上一次的確認避免重復(fù)入庫。下行階段服務(wù)端推送消息給接收端后接收端要回ACK。如果服務(wù)端沒收到ACK會走一個定時重推邏輯但重推不能無休止地進行下去一般有最大次數(shù)和衰減策略。冪等客戶端本地要有按msg_id去重的機制保證同樣的消息即便被推送多次界面上也只顯示一條。服務(wù)端寫入時也要做冪等比如通過唯一索引約束client_msg_id防止重試導(dǎo)致的重復(fù)寫入。這里我想額外提醒一個容易忽略的點ACK本身的丟失也是一種正常現(xiàn)象不要把它當(dāng)成異常去報警。我在初期做可靠性模塊時一度把“推送了消息但沒收回ACK”全部列為異常結(jié)果每天晚上被誤報警淹沒。實際上客戶端可能只是切換到后臺被系統(tǒng)凍結(jié)了等下次打開App才會補ACK。正確的做法是ACK超時重推容忍延遲而不是立刻認定為故障。3. 不同場景下的方案選型對比3.1 自研IM vs 集成第三方SDK成本、周期與掌控力每次聊到IM方案選型團隊里都繞不開“到底要不要自研”這個問題。說實話這個決策沒有標(biāo)準(zhǔn)答案取決于你的團隊規(guī)模、業(yè)務(wù)屬性和產(chǎn)品定位。自研IM的優(yōu)勢非常明顯完全可控。消息收發(fā)流程的每一個細節(jié)都掌握在自己手里想做消息雙刪、自定義表情、特殊消息類型、深度性能優(yōu)化都沒有障礙。長期來看自研IM不會產(chǎn)生按量計費的成本規(guī)模大了以后邊際成本更低。但自研IM的代價也很真實開發(fā)周期長技術(shù)棧要求高。一個能穩(wěn)定運行的消息收發(fā)系統(tǒng)至少需要長連接服務(wù)、消息存儲、離線同步、多端一致性、消息可靠投遞這些模塊團隊里如果沒有幾個精通網(wǎng)絡(luò)編程和分布式系統(tǒng)的同學(xué)很容易在上線后被各種偶發(fā)問題搞得焦頭爛額。集成第三方IM SDK或直接使用成熟的IM產(chǎn)品比如海貍IM這類專門做IM服務(wù)的產(chǎn)品或者類似CSDN盒子提供的網(wǎng)頁版IM能力最大的好處就是開箱即用。登錄、消息收發(fā)、群組、離線消息、多端同步這些能力直接調(diào)接口就行團隊可以把精力全部放在自己的業(yè)務(wù)邏輯上。我的建議是畫一條線來判斷如果你的IM只是業(yè)務(wù)里的一個輔助模塊不是核心競爭壁壘直接接成熟方案不要再自己重復(fù)造輪子。如果IM本身就是你的核心產(chǎn)品且你對數(shù)據(jù)隱私、定制化體驗有極高的要求那就要認認真真考慮自研否則業(yè)務(wù)發(fā)展到后期第三方方案的限制會成為天花板。3.2 高并發(fā)IM場景下的選型要點“高并發(fā)im”這個詞幾乎快被聊爛了但很多人聊的是“怎么堆機器”而不是“怎么設(shè)計消息收發(fā)流程以支撐高并發(fā)”。實際上高并發(fā)對消息收發(fā)流程的影響主要在三個環(huán)節(jié)。第一環(huán)是接入層。高并發(fā)意味著海量長連接同時掛載。方案選型時要重點考慮網(wǎng)關(guān)服務(wù)能不能橫向擴展客戶端重連時能不能負載均衡到不同網(wǎng)關(guān)節(jié)點同時保證消息不錯亂分布式網(wǎng)關(guān)的會話信息怎么同步我一般建議把網(wǎng)關(guān)設(shè)計成無狀態(tài)服務(wù)會話數(shù)據(jù)放在Redis或者內(nèi)存網(wǎng)格里這樣網(wǎng)關(guān)擴縮容都很容易。第二環(huán)是消息處理服務(wù)。高并發(fā)下消息處理服務(wù)必須支持多實例部署但這里有一個沖突點同一會話內(nèi)的消息必須有序處理。我在項目里的做法是按session_id對消息做一致性哈希把同一個會話的消息路由到固定的處理實例上這樣既實現(xiàn)了并行處理又能保住會話內(nèi)的順序。第三環(huán)是存儲層。高并發(fā)場景下MySQL單表存消息必然扛不住。方案選型時要預(yù)先設(shè)計好分庫分表策略比如按session_id做哈希分表或者按月分表。Redis用來做熱點消息緩存和在線狀態(tài)存儲但注意Redis不是可靠存儲關(guān)鍵消息還是要落庫。我的經(jīng)驗是高并發(fā)不是靠某一個“神器”解決的而是靠每一層的橫向擴展和合理的路由策略疊加出來的。3.3 網(wǎng)頁版IM的選型觀察從海貍IM、CSDN盒子這類產(chǎn)品說起網(wǎng)頁版IM是很多業(yè)務(wù)團隊會優(yōu)先考慮的形態(tài)因為不需要用戶下載App打開瀏覽器就能聊。做網(wǎng)頁版IM方案選型上有兩類路徑一類是用開源WebSocket框架自己搭服務(wù)端另一類是直接集成第三方IM產(chǎn)品像海貍IM這類面向業(yè)務(wù)場景的IM服務(wù)以及CSDN盒子提供的網(wǎng)頁版IM組件。自建Web端IM的優(yōu)勢是靈活整個收發(fā)流程能被你完全掌控。Web端用WebSocket做長連接自然能復(fù)用我之前講的在線推送、ACK確認、離線拉取那套流程。劣勢是Web端的使用環(huán)境比App復(fù)雜得多瀏覽器兼容性、移動端網(wǎng)絡(luò)切換、頁面刷新后的連接重建、同賬號多標(biāo)簽頁互踢這些都是在做方案評估時要充分考慮的。集成第三方網(wǎng)頁版IM產(chǎn)品最大價值是把消息收發(fā)流程整體外包出去。你不需要關(guān)心長連接怎么?；睢㈦x線消息怎么存儲、多端怎么同步SDK內(nèi)部已經(jīng)把這些做完了。如果你對IM不是強依賴深度定制這種方案會用很小的成本達到不錯的效果。我在評估這類方案時通常不會只看宣傳語而是重點追問幾件事消息可靠性怎么樣是否支持ACK確認和離線消息補償歷史消息能拉多遠數(shù)據(jù)是否屬于我方可以導(dǎo)出嗎高并發(fā)時有沒有限流策略超賣或者擴容怎么收費消息內(nèi)容是否有合規(guī)審查和內(nèi)容安全能力無論是自建還是集成網(wǎng)頁版IM的選型關(guān)鍵都在于拉齊你的業(yè)務(wù)訴求和方案的真實能力別只看“能收發(fā)消息”這個表面。3.4 開源方案與SaaS服務(wù)的取舍開源是很多技術(shù)團隊在IM選型時會考慮的中間路線。用開源的IM框架可以省掉從零開始的巨大工作量同時又能基于源碼做二次開發(fā)保留一定程度的可掌控性。這里我推薦兩個選型方向大家可以根據(jù)團隊背景來判斷如果團隊Java技術(shù)?？梢躁P(guān)注基于Netty生態(tài)的長連接框架自己搭建接入網(wǎng)關(guān)和消息處理服務(wù)配合MySQL、Redis和MQ完成整套收發(fā)流程。這種方式本質(zhì)上是“半自研”把最復(fù)雜的長連接層交給框架業(yè)務(wù)層自己實現(xiàn)。如果團隊希望更快速地落地可以直接選用成熟的IM服務(wù)端軟件部署后通過API接入自己的業(yè)務(wù)系統(tǒng)。這種方案省事但要注意開源軟件的許可證規(guī)范以及社區(qū)活躍度和后續(xù)維護風(fēng)險。開源方案的隱含成本很容易被低估導(dǎo)入代碼只是第一步后續(xù)的部署、監(jiān)控、bug修復(fù)、性能優(yōu)化全部得自己來。我見過不少團隊導(dǎo)入了一套開源IM服務(wù)端后連跑通都費了很大的勁因為缺少配套的運維文檔和排障經(jīng)驗。所以我的一個經(jīng)驗準(zhǔn)則是選擇開源方案時盡量選擇社區(qū)活躍、文檔完善、且有一定知名度的項目別用那種只發(fā)布過一版就再也沒人維護的“死碼”。4. 實操一套可落地的選型決策與部署過程4.1 選型決策的評估維度與打分表與其拍腦袋選型不如把選型變成一套可復(fù)盤的打分過程。我在實際項目里整理過一張IM方案選型評估表這里分享出來供參考評估維度權(quán)重占比自研方案評分第三方產(chǎn)品評分說明業(yè)務(wù)匹配度25%高中核心業(yè)務(wù)與IM的耦合程度交付周期15%低高上線速度是否關(guān)鍵長期成本15%中低按量收費 vs 內(nèi)部投入技術(shù)掌控力20%高低深度定制與排障能力可靠性保證15%取決于團隊取決于產(chǎn)品必須驗證不能盲信生態(tài)與維護10%需評估需評估社區(qū)/廠商的生命力打分時要注意權(quán)重分配一定要根據(jù)自己團隊的具體情況來定別照搬我的表。比如你的團隊完全沒有網(wǎng)絡(luò)編程經(jīng)驗?zāi)恰凹夹g(shù)掌控力”再高的自研方案也很難拿到高分。我的習(xí)慣是讓開發(fā)、產(chǎn)品和運維負責(zé)人一起打分打完分后把差距最大的幾項拿出來單獨討論這樣選型結(jié)論才真正站得住腳。4.2 典型消息收發(fā)架構(gòu)部署再往后就是架構(gòu)部署層面的實操了。我以一個中等規(guī)模的Web IM項目為例說一下核心組件的部署組合。接入網(wǎng)關(guān)部署2個以上實例對外通過負載均衡暴露WebSocket端口。網(wǎng)關(guān)內(nèi)實現(xiàn)連接管理、心跳超時檢測、消息編碼解碼。建議把網(wǎng)關(guān)做成無狀態(tài)節(jié)點節(jié)點宕機后客戶端能自動重連到其他節(jié)點。消息處理服務(wù)一組無狀態(tài)業(yè)務(wù)服務(wù)通過一致性哈希把同一會話的消息分發(fā)到同一實例處理。服務(wù)內(nèi)完成消息ID生成、內(nèi)容過濾、存儲寫入、推送路由。消息存儲MySQL按會話分庫分表存歷史消息Redis緩存活躍會話的近期消息和在線狀態(tài)。為了讓離線拉取更高效可以加上一層消息索引表用組合索引user_id msg_id去查。消息推送模塊作為獨立的推送服務(wù)訂閱消息隊列里的下行消息根據(jù)在線狀態(tài)決定是走長連接實時推送還是寫離線表。與網(wǎng)關(guān)之間通過內(nèi)部RPC或消息隊列通信。消息隊列解耦消息處理和消息推送。消息處理服務(wù)寫入存儲成功后把下行推送任務(wù)投遞到消息隊列推送模塊消費隊列執(zhí)行推送。這樣即使推送模塊瞬時吞吐不夠消息也不會立刻丟失。這套架構(gòu)的好處是每一層都能獨立擴容故障域隔離清晰。消息處理服務(wù)再怎么慢也不會把網(wǎng)關(guān)的連接管理拖垮推送模塊再怎么重試也不會阻塞消息寫入。4.3 核心參數(shù)與配置要點部署只是第一步真正能讓系統(tǒng)轉(zhuǎn)得穩(wěn)的是那些很少被寫在文檔里的參數(shù)調(diào)優(yōu)。我挑幾個核心配置說下我的落地經(jīng)驗。心跳超時時間建議設(shè)置為30秒發(fā)送一次心跳如果服務(wù)端90秒內(nèi)沒收到任何心跳或業(yè)務(wù)包就判定連接已死觸發(fā)資源回收。設(shè)置太短會導(dǎo)致移動網(wǎng)絡(luò)下的頻繁重連設(shè)置太長又會占用大量無效連接。我之前調(diào)試桌面端IM時把超時從90秒提到120秒網(wǎng)絡(luò)切換場景下的斷線率明顯下降了。連接最大空閑數(shù)單機長連接數(shù)是有上限的因為每個連接都要占用文件描述符和內(nèi)存。一個普通的8核16G節(jié)點跑純WebSocket網(wǎng)關(guān)保守估計可以支撐5萬到8萬并發(fā)連接具體要看每連接的消息量和內(nèi)存占用。你要在選型時對峰值連接數(shù)有預(yù)估否則到了擴容節(jié)點上限時消息收發(fā)的體驗會斷崖式下降。離線消息拉取分頁大小用戶上線時如果離線期間積累了幾百條消息一次性全量拉取會超時。建議默認分頁每頁50條到100條客戶端邊拉邊展示。另外要配合增量游標(biāo)msg_id做斷點續(xù)傳避免反復(fù)拉取重復(fù)數(shù)據(jù)。重試策略消息推送失敗后的重試間隔我習(xí)慣采用指數(shù)退避第一次1秒、第二次4秒、第三次16秒最多重試5次后轉(zhuǎn)入“待人工介入”狀態(tài)。不要用固定間隔高頻重試否則一個客戶端批量離線時服務(wù)端重試風(fēng)暴會把推送通道打爆。5. 常見問題與排查技巧實錄5.1 消息丟失從會話連接池到ACK機制的排查消息丟失是IM項目里最讓人頭疼的問題也是最常被報告的問題。我在帶項目時總結(jié)了一套排查路徑遇到“消息丟了”先別急著懷疑存儲按順序查這幾層查發(fā)送端客戶端發(fā)送后有沒有收到服務(wù)端上行確認如果一直沒收到就是上行鏈路問題優(yōu)先查接入網(wǎng)關(guān)的連接狀態(tài)。查消息處理服務(wù)服務(wù)端有沒有接到上行消息接到后有沒有把消息寫入存儲這里的日志很容易斷層所以消息處理服務(wù)每一步都要打日志包括“收到上行”“寫入成功”“推送已投遞”。查推送模塊接收端在線時走推送離線時走拉取。如果消息寫入存儲成功但接收端一直沒收到很大概率是推送模塊消費消息隊列失敗或者重試隊列發(fā)生了阻塞。查接收端接收端是否把消息成功落庫并回ACK有些時候消息其實已經(jīng)到了客戶端但客戶端的狀態(tài)展示有bug用戶就誤以為“沒收到”。排查消息丟失最關(guān)鍵的是全程日志鏈路要完整。我在項目里會在每條消息上帶一個trace_id從上行到下行全程攜帶這樣出現(xiàn)問題時能按trace_id一鍵串聯(lián)所有環(huán)節(jié)的日志。5.2 消息亂序時序約束與分段鎖消息亂序在群聊場景里尤其常見。我之前遇到過一個案例群里兩人幾乎同時發(fā)消息結(jié)果是后發(fā)送的那條先出現(xiàn)在接收端界面上用戶立刻就不滿意了。亂序的根源在于不同發(fā)送端的消息到了服務(wù)端后可能被不同的處理實例并發(fā)處理導(dǎo)致大號消息ID先被推送。要解決這個問題必須對同一個會話內(nèi)的消息處理做“串行化”。我在項目里的落地方式是給每個會話維護一把分布式分段鎖比如Redis鎖或者一致性哈希到單實例處理同一會話的消息必須串行分配消息ID和寫入存儲。但這里有個性能陷阱如果把“串行化”的范圍做得太大高并發(fā)場景下某些熱門群的吞吐會被卡住。我的優(yōu)化實踐是按session_id拆分成多個分段比如群聊按成員哈希分桶每個桶內(nèi)有自己的串行序列這樣既保證同一個發(fā)送者的消息有序又讓群消息整體的處理并行度不會太低。5.3 消息重復(fù)冪等表與唯一索引消息重復(fù)和消息丟失剛好相反但一樣傷體驗。重復(fù)消息最容易出現(xiàn)在網(wǎng)絡(luò)超時重試的場景下客戶端發(fā)送時超時了于是重發(fā)了一次但其實第一次的消息已經(jīng)寫入了服務(wù)端。解決消息重復(fù)的核心就是冪等。服務(wù)端在寫入消息之前先查一下client_msg_id是否已經(jīng)存在。為了性能我會在Redis里存一個“最近已處理的消息ID集合”同時給數(shù)據(jù)庫加唯一索引兜底。這樣即使Redis數(shù)據(jù)被清了數(shù)據(jù)庫的唯一索引也能攔住重復(fù)寫入。接收端的重復(fù)展示問題則要靠客戶端的msg_id去重?？蛻舳耸盏揭粭l消息后把msg_id放進本地去重集合界面上已經(jīng)展示過相同的msg_id就直接跳過。這里注意去重集合不能無限膨脹我一般建議只保留最近1000條消息的去重記錄更早的由業(yè)務(wù)邏輯保證。5.4 連接不穩(wěn)定心跳、重連與增量同步網(wǎng)頁版IM和移動端IM都逃不過連接不穩(wěn)定的問題。網(wǎng)絡(luò)切換、瀏覽器休眠、路由器NAT超時都會導(dǎo)致長連接意外斷開。很多用戶反饋“消息要等一會才能收到”根因往往就是連接已經(jīng)斷了但客戶端沒感知到服務(wù)端也沒及時重推。針對這個問題我的落地經(jīng)驗是三件事完善心跳的啟停策略頁面可見時保持正常心跳頁面切后臺時停止心跳但保留連接頁面恢復(fù)可見時立即發(fā)一個特殊的Ping包探測連接是否可用不可用就直接重連。重連后做增量補償客戶端重連成功后不能只依賴服務(wù)端后續(xù)推送而是要主動拉取“斷線期間可能漏掉的消息”。具體做法是客戶端帶上本地最新一條消息的msg_id服務(wù)端返回從該ID以后的所有消息這樣即使連接斷掉期間推送全丟了也能通過增量拉取補回來。多端消息同步依賴增量游標(biāo)多端登錄時每端都要維護獨立的同步游標(biāo)。這個游標(biāo)不能只存內(nèi)存必須落本地數(shù)據(jù)庫否則App一殺進程上次同步到哪了就忘了。結(jié)尾做了幾年IM項目我最大的感受是消息收發(fā)流程方案選型這件事最后選的不是某一個“?！苯M件而是選一套“適合自己團隊和業(yè)務(wù)”的完整鏈路。你可能不需要一開始就把離線表分好、把分布式鎖做好但你必須在動手前把每一個關(guān)鍵分叉點都過一遍腦子。哪怕今天先用最簡單的方案把功能跑通也要為明天的演進留好接口和余地。最后分享一個我自己的實操心得無論是選型調(diào)研還是架構(gòu)落地我都建議先把“消息產(chǎn)線”上每個環(huán)節(jié)的日志和監(jiān)控指標(biāo)搭好再動代碼。你多花在這一步上的時間在后面每次排障時會十倍百倍地還給你。畢竟IM這種東西用戶嘴上不說心里對消息及時性和可靠性的要求比任何功能點都要苛刻。