我到現(xiàn)在還記得第一次給IM項目寫心跳包時踩的坑明明兩個客戶端都顯示在線消息卻延遲了好幾秒才送達(dá)。后來才明白所謂“在線”只是一個狀態(tài)真正讓消息秒達(dá)的是一條被小心維護(hù)著的長連接。你每天打開的微信、釘釘、淘寶客服窗口甚至直播間的彈幕本質(zhì)都屬于IM即時通信的范疇。它們的業(yè)務(wù)形態(tài)千差萬別但底層要解決的問題幾乎一致建立連接、傳輸消息、確認(rèn)狀態(tài)、保證不丟。這篇文章想從技術(shù)內(nèi)核講到生活應(yīng)用把一條聊天消息從發(fā)送到送達(dá)的完整鏈路、高并發(fā)場景下的架構(gòu)拆解、常見協(xié)議選型邏輯以及我在線上真實排查過的疑難雜癥一次講清楚。不管你剛轉(zhuǎn)后端的新人、負(fù)責(zé)客服系統(tǒng)的產(chǎn)品經(jīng)理還是單純好奇“消息為什么能秒達(dá)”都能從中找到對應(yīng)的干貨。1. 一條消息從發(fā)送到送達(dá)中間到底發(fā)生了什么IM系統(tǒng)表面上看起來就是“你發(fā)一句我收一句”但這句話落到工程實現(xiàn)上涉及的路由、存儲、推送、確認(rèn)環(huán)節(jié)比想象中多。先建立整條鏈路的整體認(rèn)知后面所有架構(gòu)話題都好聊了。1.1 消息鏈路一次發(fā)送背后牽動了哪些服務(wù)假設(shè)A在微信里給B發(fā)了一句“晚上一起吃飯”從點擊發(fā)送按鈕開始這條消息大致會經(jīng)歷四個環(huán)節(jié)客戶端編碼把消息內(nèi)容、目標(biāo)用戶、消息類型等打包成約定好的二進(jìn)制或JSON結(jié)構(gòu)通過一條已經(jīng)建立好的長連接發(fā)送到服務(wù)器網(wǎng)關(guān)。網(wǎng)關(guān)接入服務(wù)器端的第一道門負(fù)責(zé)識別這條連接屬于哪個用戶、消息該轉(zhuǎn)發(fā)給哪個后端服務(wù)同時做基礎(chǔ)的頻率限制和流量控制。業(yè)務(wù)邏輯處理這里才是“理解消息”的地方。判斷接收方是否合法、是不是好友關(guān)系、消息是否需要保存、是否命中敏感詞以及決定后續(xù)怎么推送給B。存儲與推送先把消息落庫一般會存兩份一份是會話維度一份是用戶維度然后判斷B當(dāng)前是否在線。在線就直接通過B的長連接推過去不在線就寫進(jìn)離線消息表等B下次登錄再拉取。絕大多數(shù)IM系統(tǒng)跑完這一整套流程只需要幾十毫秒。但延遲低不等于可靠所以A的客戶端不會盲目相信“發(fā)出去就完了”而是會等服務(wù)端返回一個確認(rèn)ack。收到ack才把消息狀態(tài)從“發(fā)送中”改成“已發(fā)送”如果超時沒收到客戶端就會自動重發(fā)。這個設(shè)計理念可以類比寄快遞你把包裹交給快遞員網(wǎng)關(guān)快遞員回執(zhí)確認(rèn)收件ack然后快遞公司內(nèi)部轉(zhuǎn)運(yùn)業(yè)務(wù)邏輯最終由收件地址附近的網(wǎng)點派送推送。如果派送失敗系統(tǒng)會先存放離線消息直到收件人出現(xiàn)。1.2 為什么必須保持長連接輪詢的代價實在太高早期Web應(yīng)用沒有成熟的實時通信手段大家用的是輪詢前端每隔兩三秒發(fā)一個HTTP請求問服務(wù)器“有新消息嗎”。這種方式在IM場景里有兩個致命問題大部分請求都是“空輪詢”白占帶寬和服務(wù)器資源。消息到達(dá)后用戶最多只能延遲兩三秒感知談不上實時。所以IM系統(tǒng)普遍采用長連接客戶端和服務(wù)器之間建立一條TCP連接連接建立后一直保持服務(wù)器可以隨時主動把消息推給客戶端不需要客戶端反復(fù)詢問。最直觀的理解就是打電話和寫信的區(qū)別打電話是通路一直存在的全雙工通信寫信是每次都要重新投遞的短連接。如今網(wǎng)頁端最常用的是WebSocket移動端App則常見基于TCP的自定義長連接比如微信早期就是基于自研的私有TCP協(xié)議來做消息收發(fā)。長連接的核心價值在于“服務(wù)器主動推送”這是所有實時性的基礎(chǔ)。1.3 心跳機(jī)制讓服務(wù)器知道你還活著長連接雖然好用但網(wǎng)絡(luò)環(huán)境從來不是穩(wěn)定不變的。用戶進(jìn)了電梯、跨了基站W(wǎng)i-Fi斷了又連TCP連接并不會每次都被干凈地斷開很多情況下會進(jìn)入一種“半開”狀態(tài)客戶端以為連著服務(wù)器也以為連著實際上數(shù)據(jù)已經(jīng)不通了。如果服務(wù)器把這個僵尸連接一直留在內(nèi)存里后果很嚴(yán)重消息推不過去、連接數(shù)被無效占用用戶明明不在線卻顯示在線。所以IM系統(tǒng)需要一個心跳機(jī)制客戶端每隔一段時間常見是30到60秒發(fā)一個很小的心跳包給服務(wù)器。服務(wù)器記錄每個連接最近一次心跳時間。如果超過某個閾值比如90到120秒沒收到就判定連接已死主動斷開并清理會話。客戶端發(fā)現(xiàn)自己長時間沒收到服務(wù)器心跳響應(yīng)也會主動斷開重連。心跳間隔怎么定太短浪費流量和電量太長又會讓“假在線”持續(xù)太久。我見過不少剛?cè)胄械耐瑢W(xué)把心跳間隔設(shè)成5秒結(jié)果手機(jī)電量嘩嘩掉也見過設(shè)成10分鐘導(dǎo)致掉線后推送不達(dá)的。實踐中一般建議30秒上下同時讓服務(wù)端超時閾值是心跳間隔的2到3倍并允許客戶端在弱網(wǎng)模式下自動縮短間隔。2. 高并發(fā)IM架構(gòu)的核心思路把“在線”這兩個字拆開如果你只是寫一個給十個人用的聊天Demo一臺單機(jī)就夠了。但用戶量一旦上來所有問題都會暴露出來。早期我做高并發(fā)IM壓力測試時感觸最深的一句話是永遠(yuǎn)不要把所有職責(zé)放進(jìn)同一個進(jìn)程。2.1 單機(jī)瓶頸連接數(shù)本身就是一筆沉重的開銷先算一筆賬。每一條TCP長連接在服務(wù)器上至少需要占用一個文件描述符、一塊內(nèi)核緩沖區(qū)以及用于超時管理的定時器。在Go這類并發(fā)友好的語言里每個連接通常還會對應(yīng)一個goroutine在Java里則可能對應(yīng)一個線程或者EventLoop。當(dāng)單機(jī)連接數(shù)達(dá)到幾萬甚至十幾萬時CPU、內(nèi)存、文件描述符都會逼近極限。而IM場景還有個特點連接多不代表每條連接時刻都在收發(fā)消息大量連接其實是“掛著”等消息的狀態(tài)。所以單機(jī)架構(gòu)根本撐不起大規(guī)模IM必須從架構(gòu)上做橫向拆分。這也是搜“高并發(fā)im”時最常見的核心訴求不是讓一臺機(jī)器變強(qiáng)而是讓系統(tǒng)能通過加機(jī)器變強(qiáng)。2.2 網(wǎng)關(guān)層與業(yè)務(wù)層的解耦最關(guān)鍵的架構(gòu)決策高并發(fā)IM的第一步是把“維護(hù)連接”和“處理業(yè)務(wù)”分開。服務(wù)器拆分出兩層連接網(wǎng)關(guān)Gateway只負(fù)責(zé)接收、維護(hù)長連接以及把收到消息的二進(jìn)制流解碼成業(yè)務(wù)對象再轉(zhuǎn)發(fā)給下游。它不做復(fù)雜邏輯所以可以輕松水平擴(kuò)展。業(yè)務(wù)邏輯層Logic負(fù)責(zé)真正的消息路由、關(guān)系鏈校驗、存儲策略、推送決策?？蛻舳税l(fā)來的消息到達(dá)網(wǎng)關(guān)后網(wǎng)關(guān)會按照某種路由規(guī)則比如對用戶ID取模或一致性哈希轉(zhuǎn)給對應(yīng)的業(yè)務(wù)邏輯節(jié)點。業(yè)務(wù)邏輯處理完后如果需要推送再調(diào)用“推送服務(wù)”找到接收方客戶端當(dāng)前連接在哪個網(wǎng)關(guān)上把消息轉(zhuǎn)發(fā)過去。網(wǎng)關(guān)和邏輯層之間如何通信常見做法是內(nèi)部再用一套RPC或消息隊列。這樣做的好處很直接用戶量漲了只加網(wǎng)關(guān)節(jié)點即可業(yè)務(wù)規(guī)則復(fù)雜了只升級邏輯層即可兩邊互不拖累。2.3 消息隊列與寫擴(kuò)散群聊消息的高效路由群聊是IM系統(tǒng)里最考驗性能的場景之一。一個500人的群有人發(fā)一條消息理論上要把這條消息推送給499個成員。如果每個人單獨存一份那存儲成本會很可觀如果要求所有人實時拉取又會有延遲。IM行業(yè)積累下來的經(jīng)典方案是“寫擴(kuò)散”和“讀擴(kuò)散”結(jié)合寫擴(kuò)散發(fā)消息時直接給群里的每個成員生成一條會話消息記錄收件箱里放一份優(yōu)點是讀消息很快缺點是群人數(shù)越多寫入放大越嚴(yán)重。讀擴(kuò)散群里消息只存一份成員按需獲取最近的消息優(yōu)點是存儲省缺點是每次拉取要聚合。大多數(shù)IM系統(tǒng)會根據(jù)群的規(guī)模動態(tài)選擇策略。小群直接寫擴(kuò)散大群退化為讀擴(kuò)散并搭配“已讀位置”記錄。而消息從邏輯層發(fā)出之后往往會經(jīng)過消息隊列做異步扇出把同步阻塞的推送變成異步任務(wù)這樣即使瞬間有大量群消息涌入系統(tǒng)也不會被拖垮。消息隊列的另一個重要作用是削峰填谷。舉個例子電商大促期間客服IM的流量是平時的幾十倍如果所有請求都同步推給數(shù)據(jù)庫數(shù)據(jù)庫會直接被壓垮。引入隊列后寫入可以排隊消費推送可以批量執(zhí)行系統(tǒng)即使短暫過載也只是增加延遲而不是直接宕機(jī)。2.4 狀態(tài)與Session管理多端在線和踢人邏輯IM系統(tǒng)里“在線狀態(tài)”本身也是一個很重要的數(shù)據(jù)。用戶在線、離線、忙碌、離開這些狀態(tài)分散在各個網(wǎng)關(guān)節(jié)點上但業(yè)務(wù)層需要一個全局視角。所以常規(guī)做法是把會話信息抽出來放到Rediskey通常是userIdvalue則包含當(dāng)前登錄的設(shè)備列表、每個設(shè)備連接所在的網(wǎng)關(guān)節(jié)點ID、最近心跳時間等。用戶登錄成功后業(yè)務(wù)層通過分布式鎖保證同一個賬號同一設(shè)備只有一個連接重復(fù)登錄時老連接會被踢下線或提示“賬號在其他設(shè)備登錄”。狀態(tài)變更還需要廣播給相關(guān)聯(lián)系人比如你上線了你的好友列表會顯示“在線”。這個動作如果全量廣播社交大V會瞬間讓推送服務(wù)爆炸所以一般會加上頻控和好友分群推送。不要小看這些細(xì)節(jié)高并發(fā)IM里很多線上問題都出在這種“看似簡單”的狀態(tài)同步上。3. 協(xié)議選型XMPP、MQTT、WebSocket和自研私有協(xié)議怎么選聊完架構(gòu)下一個繞不開的問題是客戶端和服務(wù)器之間用什么協(xié)議通信協(xié)議決定研發(fā)效率、兼容性、流量開銷以及可維護(hù)性。沒有絕對的最好只有適合場景的方案。3.1 XMPP老牌IM協(xié)議為什么漸漸邊緣化XMPP可擴(kuò)展消息處理協(xié)議誕生于IM領(lǐng)域早期核心是基于XML流的數(shù)據(jù)交換強(qiáng)調(diào)聯(lián)邦互通和擴(kuò)展性。它的優(yōu)勢是標(biāo)準(zhǔn)成熟、實現(xiàn)豐富、社區(qū)文檔多早期包括Google Talk都用過。但它在移動時代的軟肋太明顯XML冗余大傳輸效率低弱網(wǎng)下表現(xiàn)差。而且XMPP雖然擴(kuò)展性強(qiáng)但默認(rèn)能力并不覆蓋移動端的“消息到達(dá)確認(rèn)”“離線消息拉取”“多端同步”等IM必備功能需要大量擴(kuò)展協(xié)議去補(bǔ)等于繼承了一個框架又自己造了一輛整車。今天新啟動的IM項目除非有特殊兼容需求幾乎沒人再從零選XMPP了。它的價值更多體現(xiàn)在歷史系統(tǒng)和跨組織通信場景。3.2 MQTT弱網(wǎng)與物聯(lián)網(wǎng)場景的實用選擇MQTT最早是為衛(wèi)星通信和物聯(lián)網(wǎng)設(shè)計的基于發(fā)布/訂閱模型非常適合帶寬有限、網(wǎng)絡(luò)不穩(wěn)定的設(shè)備。它自帶三個QoS等級QoS 0至多一次可能丟消息。QoS 1至少一次可能重復(fù)。QoS 2恰好一次保證不重不丟代價是性能開銷大。IM場景一般用QoS 1就能滿足“不丟但允許重復(fù)”的需求配合客戶端去重即可。很多IoT設(shè)備推送比如智能門鎖報警、遠(yuǎn)程控制指令都跑在MQTT上。它有個額外的好處是Broker消息代理生態(tài)成熟EMQX、Mosquitto都是常用組件部署和維護(hù)成本比較低。如果你的IM場景主要在弱網(wǎng)環(huán)境比如車載、戶外定位設(shè)備、低功耗傳感器MQTT比自研私有協(xié)議劃算得多。3.3 WebSocket網(wǎng)頁端IM的事實標(biāo)準(zhǔn)WebSocket可以理解為跑在TCP之上、通過HTTP握手建立的全雙工協(xié)議。瀏覽器的原生支持讓它成了網(wǎng)頁聊天、在線客服、協(xié)同辦公類產(chǎn)品的默認(rèn)選擇。你不需要安裝客戶端打開瀏覽器就能用這也是網(wǎng)上經(jīng)常有人搜“csdn盒子im網(wǎng)頁版”“某某IM網(wǎng)頁版”的原因——本質(zhì)上就是想要一個免安裝、拿來即用的網(wǎng)頁聊天工具。WebSocket的優(yōu)點是和HTTP生態(tài)天然融合鑒權(quán)可以用已有的登錄態(tài)消息可以用JSON傳遞出錯時的錯誤碼可以借用HTTP語義。缺點是協(xié)議本身不提供消息可靠投遞、回執(zhí)重傳等機(jī)制這些都得業(yè)務(wù)層自己補(bǔ)。實際項目中WebSocket通常和HTTP接口混合使用HTTP負(fù)責(zé)查詢類操作拉好友列表、拉歷史消息WebSocket負(fù)責(zé)實時消息收發(fā)。這個分工模式成熟且高效絕大多數(shù)中大型Web IM都是這么做的。3.4 自研私有協(xié)議大廠為什么寧可自己造輪子微信、QQ這類億級用戶產(chǎn)品最終都會走向自研協(xié)議。原因主要有幾點包體更小用二進(jìn)制或protobuf代替JSON同樣的消息能省一半以上流量?？刂屏Ω鼜?qiáng)加密方案、重傳策略、連接遷移、多路復(fù)用都能按自己的需求縱深優(yōu)化。業(yè)務(wù)粘合度更高消息、朋友圈、支付、小程序都跑在同一條連接上統(tǒng)一調(diào)度更加順暢。當(dāng)然自研協(xié)議的代價也很高客戶端、服務(wù)端都要維護(hù)編解碼層通信格式變更要嚴(yán)格做兼容測試成本翻倍。所以我的建議是如果你的團(tuán)隊規(guī)模、用戶體量還沒到那個階段不要輕易自研。這里整理一張常見協(xié)議選型對比表供參考協(xié)議傳輸效率實時性弱網(wǎng)表現(xiàn)典型場景XMPP低高中歷史IM、聯(lián)邦通信MQTT中高高強(qiáng)IoT、車載、弱網(wǎng)設(shè)備WebSocket中高中網(wǎng)頁IM、在線客服自研TCP私有協(xié)議高高強(qiáng)億級用戶IM、直播彈幕4. 從社交App到客服工作臺不同場景的IM落地差異很多資料討論IM時只盯著“聊天”這一個動作但真實的IM產(chǎn)品是分行業(yè)的。熟人社交里的IM和客服系統(tǒng)里的IM優(yōu)化目標(biāo)完全不同。4.1 熟人社交IM消息必達(dá)和順序是底線微信、短信這類熟人社交場景用戶最不能容忍的是“消息丟了”和“順序亂了”。所以工程重點放在每條消息有唯一的服務(wù)端序列號接收方按序列號排序避免亂序。發(fā)送方必須收到ack才算成功否則自動重傳服務(wù)端做冪等去重。多端同步時各端維護(hù)一個游標(biāo)cursor離線期間的消息登錄后一起拉取。這個場景還有一個用戶感知極強(qiáng)的功能已讀回執(zhí)。它服務(wù)端不需要把“已讀”做成實時消息更常見的做法是讓接收方在打開會話時匯報一下“我的已讀位置”服務(wù)端再異步通知發(fā)送方。4.2 客服與營銷場景會話分配和消息合并更關(guān)鍵客服IM面對的通常不是“對等的聊天”而是“一個用戶面對一個坐席”。它有幾個完全不同的核心問題會話路由用戶進(jìn)來后系統(tǒng)自動分配一個空閑坐席可能還要考慮技能組、客戶等級、歷史接待人。消息排隊高峰時坐席不夠用戶消息要進(jìn)隊列并明確展示“前面還有幾位”。機(jī)器人轉(zhuǎn)人工先由機(jī)器人應(yīng)答根據(jù)語義判斷是否需要人工介入轉(zhuǎn)移時要把上下文一并帶上?？头蘒M的商業(yè)價值遠(yuǎn)遠(yuǎn)不止“聊天功能”。它需要和CRM、工單、知識庫打通消息往往要轉(zhuǎn)成可跟蹤的業(yè)務(wù)記錄。所以這個賽道的技術(shù)重心不是把單條消息延遲壓到幾十毫秒而是把路由、排隊、狀態(tài)機(jī)和業(yè)務(wù)系統(tǒng)無縫縫合起來。4.3 網(wǎng)頁版與嵌入式IM瀏覽器生態(tài)的特殊問題網(wǎng)頁版IM的需求長期存在。很多企業(yè)想在官網(wǎng)加一個“在線咨詢”按鈕想在后臺管理系統(tǒng)里嵌入站內(nèi)信模塊或者做一個只有單一功能的IM網(wǎng)頁版供內(nèi)部使用。這類場景繞不開瀏覽器兼容和單頁應(yīng)用帶來的特殊問題。一個很常見的現(xiàn)象是聊天組件用著用著控制臺突然報出類似“failed to fetch dynamically im”的錯誤。這個報錯本身信息量很少關(guān)鍵詞是“動態(tài)獲取”和“fetch”。我排查過的案例里多數(shù)都是前端在初始化聊天配置時動態(tài)拉取會話Token或者用戶檔案的接口出了問題比如Token過期但前端還在用舊Token發(fā)消息?？缬蚺渲貌煌暾麨g覽器攔截了接口響應(yīng)。網(wǎng)絡(luò)切換導(dǎo)致請求發(fā)出去了但響應(yīng)超時。后端返回的數(shù)據(jù)結(jié)構(gòu)里少了某個字段前端解構(gòu)時直接拋錯。這類問題的排查思路放在下一章詳細(xì)展開。這里只想提醒一點網(wǎng)頁版IM對于“優(yōu)雅降級”的要求更高連接失敗時至少要讓用戶能夠刷新重試并給出可讀的提示而不是控制臺一片紅頁面卻沒有反應(yīng)。4.4 IM能力的外溢IoT通知、遠(yuǎn)程協(xié)作、直播彈幕IM并不只在聊天軟件里出現(xiàn)。萬物互聯(lián)的背景下IM的核心能力“長連接實時推送”被復(fù)用在大量生活化場景家里的智能門鎖開鎖報警、快遞柜取件通知本質(zhì)是一個單向IM推送通道。在線文檔多人同時編輯時光標(biāo)位置和評論提醒需要低延遲通道也常復(fù)用WebSocket。直播彈幕、在線答題、遠(yuǎn)程白板底層同樣是消息分發(fā)。這也是為什么理解IM架構(gòu)的價值不止于做聊天應(yīng)用。任何需要“實時”二字的產(chǎn)品都離不開這套內(nèi)核能力。很多時候你不是在設(shè)計一個聊天軟件而是在設(shè)計一個實時協(xié)同的底座而IM就是這個底座最經(jīng)典的形態(tài)。5. 線上IM故障排查那些我踩過的坑和定位套路紙上得來終覺淺。IM系統(tǒng)上線之后的故障排查才是真正拉開工程師差距的地方。我這里整理幾個高頻問題重點講定位思路而不是直接給答案因為這些坑換成別的項目往往只是報錯文案不同而已。5.1 “連接不上”先分清是網(wǎng)絡(luò)、網(wǎng)關(guān)還是客戶端問題用戶報“消息發(fā)不出去”“一直連接中”第一件事永遠(yuǎn)不是改代碼而是分層排查。我習(xí)慣按這樣的順序來確認(rèn)當(dāng)前用戶是否完全離線。如果只有某個用戶離線大概率是客戶端本地狀態(tài)異?；蚴窃撚脩舻臅挶环?wù)端踢下了線?？淳W(wǎng)關(guān)實時連接數(shù)。如果整體連接數(shù)大幅下降說明是網(wǎng)關(guān)或網(wǎng)絡(luò)層出了問題可能是機(jī)房網(wǎng)絡(luò)抖動、網(wǎng)關(guān)節(jié)點OOM。在客戶端抓日志看連接失敗的階段是TCP建連失敗還是證書校驗失敗還是WebSocket握手返回了非預(yù)期狀態(tài)碼。重點檢查NAT超時引發(fā)的半開連接。很多游客網(wǎng)絡(luò)下TCP連接被運(yùn)營商/路由器靜默回收但兩端都不知道。用戶看起來在線實際已經(jīng)失聯(lián)。這種情況最常見的解決方案就是前文說的心跳機(jī)制和自動重連。5.2 消息發(fā)不出去ack超時的定位鏈路如果連接正常但某些消息發(fā)不出去矛頭就要指向消息鏈路的某個環(huán)節(jié)。發(fā)送方的表現(xiàn)通常是“消息一直轉(zhuǎn)圈”或狀態(tài)變成“發(fā)送失敗”。定位的時候別盯著客戶端猜去看服務(wù)端日志里有沒有收到這條消息。實操套路是這樣給每條消息一個全局唯一的客戶端消息IDclientMsgId。排查時先按這個ID查網(wǎng)關(guān)日志、邏輯層日志、存儲日志看消息到底走到了哪一步。如果網(wǎng)關(guān)收到了但邏輯層沒處理問題大概率在路由或鑒權(quán)。如果邏輯層處理了但推送沒成功要查接收方是否在線、Session信息是否過期、推送服務(wù)是否報錯。有一次我們線上出現(xiàn)過偶發(fā)消息丟失最后發(fā)現(xiàn)是邏輯層在并發(fā)場景下漏判了接收方的在線狀態(tài)導(dǎo)致消息只存不推客戶端又不知道去拉離線消息。解決方式是調(diào)整狀態(tài)判斷邏輯同時讓客戶端在重連或回到前臺時主動拉取一次離線消息作為兜底。5.3 “failed to fetch dynamically …”這類動態(tài)獲取失敗的完整排查前面提過的控制臺報錯“failed to fetch dynamically im”報錯本身非常含糊但本質(zhì)上是在說“前端頁面動態(tài)獲取某個IM相關(guān)資源時網(wǎng)絡(luò)請求失敗了”。我排查過最具代表性的一次場景是前端聊天插件初始化時會先向服務(wù)端請求一個動態(tài)配置內(nèi)容包括當(dāng)前用戶綁定的客服分組、歡迎語、WebSocket地址等。某天部分用戶反饋聊天窗口打不開控制臺就是這個報錯。我當(dāng)時的排查順序是先看瀏覽器Network面板找到真正失敗的接口確認(rèn)返回狀態(tài)碼。結(jié)果發(fā)現(xiàn)是HTTP 401。打開接口日志發(fā)現(xiàn)這些用戶攜帶的會話票據(jù)已經(jīng)過期。原因是頁面長期未刷新前端卻用舊的票據(jù)去請求新配置。解決方案分兩處后端在票據(jù)過期時返回明確錯誤碼前端捕獲該錯誤碼后靜默刷新票據(jù)并重試一次而不是直接把異常拋給用戶。這個案例給我的啟示是動態(tài)獲取類報錯十有八九不是網(wǎng)絡(luò)斷了而是配套的“授權(quán)態(tài)”和“數(shù)據(jù)格式”出了問題。先看接口返回比死磕前端代碼有效得多。5.4 高并發(fā)下的消息丟失如何在壓力里找真相高并發(fā)導(dǎo)致的故障往往不像普通bug那么自然復(fù)現(xiàn)它更像“壓力到了某個閾值后突然爆發(fā)”。消息丟失類問題的高發(fā)點主要在三個地方消息隊列積壓扇出消息的生產(chǎn)速度遠(yuǎn)大于消費速度消費者處理不過來產(chǎn)生超時和丟棄。Redis異常Session或離線消息依賴Redis如果Redis出現(xiàn)大key、慢查詢或集群節(jié)點切換整個鏈路都會抖動。IO線程阻塞某些服務(wù)把耗時的讀寫操作直接放在了IO線程里一旦數(shù)據(jù)庫或外部接口變慢所有消息都堵在入口。應(yīng)對這類問題最重要的前置動作是日志里有消息全鏈路的軌跡。建議在網(wǎng)關(guān)收到消息、邏輯層處理完、推送成功這三個關(guān)鍵節(jié)點都打上同一批消息ID的日志。排查時通過消息ID把三段日志拼在一起一眼就能看出消息斷在了哪里。平時壓測時也要提前驗證如果單臺網(wǎng)關(guān)掛了連接會不會自動遷移消息隊列堆積十萬條時系統(tǒng)是否能迅速恢復(fù)這些演練做多了真正線上出事時才不會手忙腳亂。6. 一周做一個最小可運(yùn)行的IM從Demo到基本能用的實踐路講了這么多理論最后給想親手驗證的同學(xué)一條可執(zhí)行的路徑。我建議不要一上來就去復(fù)刻微信而是從“網(wǎng)頁版單聊工具”做起這個范圍恰好能覆蓋IM的核心環(huán)節(jié)又控制在一周業(yè)余時間內(nèi)。6.1 技術(shù)棧和項目結(jié)構(gòu)一個最小可運(yùn)行IM技術(shù)棧不必復(fù)雜后端Node.js或Go任選一個你熟的。Go更貼近生產(chǎn)環(huán)境Node.js寫起來更省事。通信WebSocket瀏覽器端天然支持省去寫TCP客戶端的時間。存儲Redis存在線狀態(tài)和離線消息順手解決“消息過期”問題MySQL存歷史消息和用戶賬號數(shù)據(jù)。目錄結(jié)構(gòu)可以這樣規(guī)劃im-demo/ ├── server/ # WebSocket服務(wù)端 │ ├── auth.go # 登錄與Token校驗 │ ├── hub.go # 連接管理、消息路由 │ └── message.go # 消息結(jié)構(gòu)與存儲 ├── web/ # 前端頁面 │ ├── index.html # 聊天界面 │ └── chat.js # WebSocket客戶端 └── data/ # Redis/MySQL初始化腳本這個項目不需要微服務(wù)不需要消息隊列等跑通后再去演進(jìn)也不遲。6.2 核心流程從登錄到WebSocket連接整個流程很簡單用戶在頁面輸入用戶名密碼調(diào)用HTTP接口登錄服務(wù)端校驗后返回一個Token。前端拿著Token去連WebSocket服務(wù)端在握手階段校驗Token并建立會話。連接建立后服務(wù)端把連接注冊進(jìn)內(nèi)存管理結(jié)構(gòu)并往Redis寫入用戶狀態(tài)。發(fā)消息時客戶端發(fā)送JSON例如{type:chat,to:userB,content:hello,clientMsgId:uuid-001}。服務(wù)端收到后先落庫再根據(jù)to字段找到接收方的WebSocket連接把消息推過去。這里有個容易忽略的點服務(wù)端推送給接收方時也要把消息ID帶上接收方客戶端需要做去重。因為如果推送超時發(fā)送方可能會重發(fā)同一條消息。6.3 離線消息、歷史消息和已讀回執(zhí)在線用戶直接推送離線用戶的消息則不能丟。最小版本的做法是推送失敗時把消息追加到Redis里以用戶ID為key的List結(jié)構(gòu)中。用戶下次登錄建立連接后服務(wù)端把List里未讀消息一次性撈出來發(fā)給他然后清空List。歷史消息更簡單MySQL里存一份消息表字段大致是msg_id, from_user, to_user, content, created_at。打開會話時按這兩個用戶的組合查最近50條即可。已讀回執(zhí)可以放在最后做接收方打開聊天窗口時發(fā)送一個{type:read,lastMsgId:123}服務(wù)端把這個已讀位置更新到Redis再異步通知對方。這個功能雖然簡單但足以幫你理解“狀態(tài)同步”的核心邏輯。6.4 壓測與調(diào)優(yōu)別讓Demo只是Demo項目跑通之后建議做一次最簡單的壓測讓“高并發(fā)”這個抽象的詞落地。工具可以使用wsbench或自己寫個腳本模擬一百個并發(fā)連接。重點關(guān)注三個指標(biāo)最大連接數(shù)服務(wù)端能穩(wěn)定掛住多少條連接。消息吞吐量單位時間內(nèi)能轉(zhuǎn)發(fā)多少條消息。錯誤率消息發(fā)送失敗、重復(fù)投遞的比例。我第一次做這種Demo時就發(fā)現(xiàn)如果每來一條消息都同步寫一次MySQL消息吞吐量會被拖到慘不忍睹。后來改成異步批量寫內(nèi)存里攢夠一定數(shù)量再落庫吞吐量立刻翻了幾倍。這就是一個最簡單的IM性能優(yōu)化案例也是從Demo走向可用的必經(jīng)之路。最后說一點我自己的體會。IM這個東西入門門檻并不高任何程序員都能在一周內(nèi)寫出能聊天的Demo但真正難的是在復(fù)雜的網(wǎng)絡(luò)環(huán)境、高并發(fā)流量、多端同步、消息可靠性這些層面把細(xì)節(jié)磨扎實。如果你正在做一個IM相關(guān)的項目我的建議是不要迷信任何現(xiàn)成框架而是親手把消息鏈路走一遍把連接、存儲、推送、確認(rèn)這些環(huán)節(jié)逐步打通。哪怕只是抱著學(xué)習(xí)目的做一個小Demo這個過程都會讓后面讀任何IM的代碼都清晰很多。