簡(jiǎn)介基于WebSocket的LAS多端互通畢業(yè)設(shè)計(jì)項(xiàng)目面向需要實(shí)現(xiàn)實(shí)時(shí)位置感知與多端數(shù)據(jù)同步的開(kāi)發(fā)者重點(diǎn)解決傳統(tǒng)HTTP只能請(qǐng)求/響應(yīng)、無(wú)法主動(dòng)推送導(dǎo)致的位置信息滯后問(wèn)題。壓縮包共55個(gè)文件包含46個(gè)Python源碼文件、7張JPG效果圖、1個(gè)Markdown說(shuō)明文檔及License文件整體僅485KB輕量而完整。項(xiàng)目采用服務(wù)端集中轉(zhuǎn)發(fā)與客戶(hù)端異步接入的方式并配有插件化模塊設(shè)計(jì)覆蓋聊天橋接、在線(xiàn)玩家查詢(xún)、簽到、坐標(biāo)共享等典型場(chǎng)景源碼對(duì)服務(wù)端、客戶(hù)端、插件邏輯做了清晰劃分JPG預(yù)覽圖可直觀對(duì)照運(yùn)行效果便于快速理解WebSocket雙向通信在LAS系統(tǒng)中的應(yīng)用機(jī)制。目前已有38人學(xué)習(xí)參考適合作為畢業(yè)設(shè)計(jì)參考或課程項(xiàng)目拓展也可在讀懂核心流程后自行擴(kuò)展消息類(lèi)型與前端交互界面尤其能體現(xiàn)對(duì)通信協(xié)議與工程結(jié)構(gòu)的綜合運(yùn)用。1. 基于WebSocket的LAS多端互通先說(shuō)清楚這東西解決什么中午改完桌面端的排班模板手機(jī)上的小程序要能立刻看到新?tīng)顟B(tài)而不是等用戶(hù)手動(dòng)刷新或者輪詢(xún)兜底。這就是LAS多端互通最典型的場(chǎng)景一套業(yè)務(wù)服務(wù)同時(shí)掛了桌面端、手機(jī)端、網(wǎng)頁(yè)端任何一端產(chǎn)生變化其它端要在秒級(jí)內(nèi)感知到。傳統(tǒng)HTTP做不到實(shí)時(shí)下行推送WebSocket長(zhǎng)連接才是承擔(dān)這個(gè)角色的主干。標(biāo)題里的LAS在這里不是某個(gè)公開(kāi)標(biāo)準(zhǔn)它就是一個(gè)業(yè)務(wù)代號(hào)你可以把它映射成你手頭任何一套需要多端協(xié)作的系統(tǒng)名。「基于WebSocket的LAS多端互通.zip」拆開(kāi)看就三件事用WebSocket建立長(zhǎng)連接在連接之上做LAS業(yè)務(wù)消息的轉(zhuǎn)發(fā)再解決多端同時(shí)在線(xiàn)的身份識(shí)別與消息路由。比做一個(gè)單聊或通知推送復(fù)雜的地方在于同一個(gè)用戶(hù)可能同時(shí)在電腦瀏覽器、手機(jī)App、微信小程序里掛著服務(wù)端得知道一條消息該發(fā)給哪幾個(gè)連接哪些連接其實(shí)已經(jīng)死了以及消息發(fā)過(guò)去之后對(duì)方到底收沒(méi)收到。這篇筆記適合兩類(lèi)人。一類(lèi)是后端要接WebSocket但之前只寫(xiě)過(guò)接口的能跟著把連接管理、心跳機(jī)制和消息路由跑起來(lái)另一類(lèi)是前端要把網(wǎng)頁(yè)、小程序、桌面端接到同一套實(shí)時(shí)鏈路上的看完能知道服務(wù)端是怎么判定自己掉線(xiàn)的以及前端該怎么配合。下面所有代碼我都按Node.js的ws庫(kù)來(lái)寫(xiě)這套方案換到Netty、Spring WebSocket或者Go的gorilla/websocket上思路是同一套。2. 連接管理是互通的底座把每個(gè)端變成可尋址的對(duì)象多端互通的第一步不是寫(xiě)消息轉(zhuǎn)發(fā)而是先讓服務(wù)端能認(rèn)得出每一個(gè)連接。裸的WebSocket連接在服務(wù)端只是一個(gè)socket對(duì)象它不知道自己屬于哪個(gè)用戶(hù)、哪個(gè)端、在哪個(gè)房間。如果直接拿這個(gè)socket做消息收發(fā)你會(huì)很快發(fā)現(xiàn)代碼變成一團(tuán)亂麻要廣播的時(shí)候不知道發(fā)給誰(shuí)用戶(hù)換設(shè)備登錄后舊連接也沒(méi)法處理。所以第一層要做的是給連接套上身份。2.1 為什么不能直接用裸連接來(lái)收發(fā)消息很多第一次接觸WebSocket的人會(huì)直接這樣寫(xiě)connection事件里拿到socket然后往socket上綁onmessage收到什么轉(zhuǎn)發(fā)什么。單連接demo沒(méi)問(wèn)題一旦出現(xiàn)「用戶(hù)A在手機(jī)上發(fā)一條消息他桌面端和網(wǎng)頁(yè)端也要同時(shí)收到」光有socket就不夠了因?yàn)榉?wù)端根本沒(méi)有「用戶(hù)」這個(gè)概念只有一堆不知道是誰(shuí)的連接。LAS多端互通里最常見(jiàn)的狀態(tài)是一個(gè)用戶(hù)同時(shí)掛了三個(gè)連接三個(gè)連接的契約還可能不一樣——網(wǎng)頁(yè)端只關(guān)心排班變更桌面端還會(huì)同步模板文件手機(jī)端要收審批通知。你不能把這三類(lèi)消息無(wú)差別群發(fā)給所有連接。所以必須在連接之上加一層會(huì)話(huà)Session抽象把「物理連接」和「邏輯身份」分開(kāi)。連接斷開(kāi)只會(huì)影響某個(gè)connId而用戶(hù)的多個(gè)連接之間是弱關(guān)聯(lián)其中一個(gè)掉了不應(yīng)該影響另外兩個(gè)繼續(xù)收消息。我一般會(huì)把連接生命周期里的注冊(cè)、心跳、鑒權(quán)、路由全部收口到一個(gè)ConnectionManager里業(yè)務(wù)層不直接碰ws對(duì)象。這樣做還有個(gè)好處將來(lái)把單機(jī)改成多實(shí)例部署時(shí)ConnectionManager內(nèi)部換成Redis維護(hù)連接索引業(yè)務(wù)代碼不用動(dòng)。2.2 連接注冊(cè)clientId 與 connectionId 的雙層索引先定協(xié)議客戶(hù)端握手時(shí)在URL的query里帶clientId這個(gè)ID代表一個(gè)業(yè)務(wù)用戶(hù)由LAS自己的登錄態(tài)生成服務(wù)端每接受一條連接就生成一個(gè)全局唯一的connectionId。中間層維護(hù)三張表connMapconnectionId - WebSocket 實(shí)例用于直接發(fā)消息userMapclientId - Set 用于按用戶(hù)找到他所有的端roomMaproomId - Set 用于按房間做廣播。下面是最小可運(yùn)行的注冊(cè)邏輯// server.js —— WebSocket 連接注冊(cè)與用戶(hù)索引維護(hù) const { WebSocketServer } require(ws); const crypto require(crypto); const connMap new Map(); // connectionId - ws const userMap new Map(); // clientId - SetconnectionId // 用 wss 實(shí)例監(jiān)聽(tīng)端口按 LAS 網(wǎng)關(guān)配置調(diào)整比如 8080 const wss new WebSocketServer({ port: 8080, maxPayload: 64 * 1024 * 1024 // 允許 64MB 單幀給文件類(lèi)消息留余量 }); function parseClientId(url) { // 握手地址形如: /?clientIdU10086tokenxxx // 生產(chǎn)環(huán)境這里的 token 要做簽名校驗(yàn)不能用純明文 return new URLSearchParams(url.split(?)[1]).get(clientId); } wss.on(connection, (ws, req) { const connId crypto.randomUUID(); const clientId parseClientId(req.url); if (!clientId) { ws.close(4001, missing clientId); // 握手失敗直接斷開(kāi) return; } connMap.set(connId, ws); if (!userMap.has(clientId)) userMap.set(clientId, new Set()); userMap.get(clientId).add(connId); // 把 connId 掛到 ws 上后面 onmessage 里好取 ws.connId connId; ws.clientId clientId; ws.on(close, () { connMap.delete(connId); const conns userMap.get(clientId); if (conns) { conns.delete(connId); if (conns.size 0) userMap.delete(clientId); } }); });注冊(cè)這段邏輯里parseClientId 從握手URL解析業(yè)務(wù)用戶(hù)ID這個(gè)設(shè)計(jì)是故意的WebSocket 的握手就是一次普通HTTP請(qǐng)求可以把鑒權(quán)信息放進(jìn)query或header不要在建立連接之后再單獨(dú)發(fā)一條「登錄消息」——那樣會(huì)給中間層留下一個(gè)沒(méi)身份的空窗期。ws.close(4001, missing clientId) 是拒絕握手的標(biāo)準(zhǔn)姿勢(shì)客戶(hù)端會(huì)收到4001錯(cuò)誤碼并觸發(fā)onclose便于前端區(qū)分「被拒」和「網(wǎng)絡(luò)斷開(kāi)」。注意maxPayload這個(gè)參數(shù)。LAS如果涉及模板文件、簡(jiǎn)報(bào)圖片甚至點(diǎn)云預(yù)覽單幀消息很容易超過(guò)默認(rèn)1MB上限。我按64MB開(kāi)是給大數(shù)據(jù)量消息留余地但代價(jià)是內(nèi)存壓力增加業(yè)務(wù)不需要傳大文件時(shí)建議調(diào)回1MB~8MB。2.3 房間分組把廣播范圍圈出來(lái)多端互通不可能所有消息都發(fā)給所有人。LAS里典型的房間模型是「項(xiàng)目組」一個(gè)項(xiàng)目組的變更消息只需要推給這個(gè)組里的人跨組消息屬于越權(quán)。所以第三張表roomMap做的事就是把連接歸組。// room.js —— 房間管理基于 Set 做連接維度分組 const roomMap new Map(); // roomId - SetconnectionId function joinRoom(connId, roomId) { if (!roomMap.has(roomId)) roomMap.set(roomId, new Set()); roomMap.get(roomId).add(connId); } function leaveRoom(connId, roomId) { roomMap.get(roomId)?.delete(connId); } function broadcastToRoom(roomId, message) { const conns roomMap.get(roomId); if (!conns) return; const raw JSON.stringify(message); for (const connId of conns) { const ws connMap.get(connId); // readyState 1 表示連接處于 OPEN 狀態(tài)防止往 CLOSED 連接上寫(xiě) if (ws ws.readyState 1) ws.send(raw); } }這里有一個(gè)需要想清楚的點(diǎn)房間維度到底按clientId還是connectionId。我上面是按connectionId存的好處是一個(gè)用戶(hù)多個(gè)端在不同房間時(shí)互不干擾代價(jià)是用戶(hù)換房間要做兩次leaveRoomjoinRoom。如果你確定一個(gè)用戶(hù)所有端永遠(yuǎn)在同一個(gè)房間就按clientId存房間每次廣播時(shí)先展開(kāi)成connectionId列表再發(fā)送省掉一部分重復(fù)消息。兩個(gè)方案都能跑選擇標(biāo)準(zhǔn)只有一個(gè)你的業(yè)務(wù)允不允許同一個(gè)人的兩個(gè)端處在不同項(xiàng)目組。3. WebSocket心跳機(jī)制實(shí)現(xiàn)服務(wù)端如何判斷「對(duì)方還活著」連接建立不等于連接健康。LAS多端互通里最常見(jiàn)的翻車(chē)現(xiàn)場(chǎng)是客戶(hù)端突然從4G切到Wi-FiTCP連接已經(jīng)死了但服務(wù)端和客戶(hù)端都沒(méi)有立刻感知服務(wù)端還往這個(gè)死連接上發(fā)消息客戶(hù)端一直收不到也不重連。要解決這個(gè)問(wèn)題必須有一套心跳機(jī)制。這也是WebSocket長(zhǎng)連接工程里最值得摳細(xì)節(jié)的部分。3.1 心跳機(jī)制實(shí)現(xiàn)為什么是服務(wù)端主動(dòng) ping 而不是讓客戶(hù)端表態(tài)網(wǎng)上很多方案是客戶(hù)端定時(shí)發(fā)一個(gè){type:heartbeat}給服務(wù)端服務(wù)端收到就更新lastSeen。這種做法能用但它有個(gè)隱患客戶(hù)端的定時(shí)器和網(wǎng)絡(luò)棧是獨(dú)立的即使鏈路已經(jīng)半斷開(kāi)客戶(hù)端的setInterval照樣觸發(fā)并調(diào)用ws.sendsend不報(bào)錯(cuò)并不代表數(shù)據(jù)真的到了對(duì)端。標(biāo)準(zhǔn)做法是服務(wù)端用WebSocket協(xié)議層的ping/pong控制幀。ws庫(kù)的底層會(huì)自動(dòng)響應(yīng)協(xié)議層的pong幀所以服務(wù)端只要定時(shí)ping然后統(tǒng)計(jì)這個(gè)周期內(nèi)有沒(méi)有收到pong就能精確知道TCP鏈路是否通著?？刂茙蛔邩I(yè)務(wù)消息隊(duì)列比應(yīng)用層心跳更省資源、判定更準(zhǔn)。3.2 心跳代碼與參數(shù)間隔、誤判閾值、重連退避// heartbeat.js —— 基于 ws 庫(kù)的協(xié)議層心跳間隔 30s容忍 2 個(gè)周期無(wú)響應(yīng) const aliveSet new Set(); // 記錄“本周期內(nèi)回過(guò) pong”的連接 wss.on(connection, (ws) { aliveSet.add(ws); ws.on(pong, () aliveSet.add(ws)); ws.on(close, () aliveSet.delete(ws)); }); const HEARTBEAT_INTERVAL 30_000; // 每 30s 檢查一輪 const HEARTBEAT_TIMEOUT 60_000; // 距離上一次 pong 超過(guò) 60s 視為死亡 setInterval(() { for (const ws of wss.clients) { if (ws.readyState ! ws.OPEN) { aliveSet.delete(ws); ws.terminate(); // 直接掐斷觸發(fā)客戶(hù)端重連 continue; } if (aliveSet.delete(ws)) { ws.ping(); // 本周期有 pong繼續(xù)探活 } else { // 上一周期沒(méi)收到 pong說(shuō)明鏈路已經(jīng)斷了 ws.terminate(); } } }, HEARTBEAT_INTERVAL);這套邏輯的關(guān)鍵在aliveSet.delete(ws)的返回值每輪進(jìn)入定時(shí)器時(shí)如果這個(gè)連接在上一個(gè)周期內(nèi)回過(guò)pongdelete會(huì)返回true然后重新ping如果返回false說(shuō)明這個(gè)連接已經(jīng)整整一個(gè)心跳周期沒(méi)有回應(yīng)直接terminate。terminate和close的區(qū)別值得注意close是禮貌地走完關(guān)閉握手但TCP層可能已經(jīng)死了close發(fā)不出去terminate是直接銷(xiāo)毀底層socket立刻生效。服務(wù)端探活發(fā)現(xiàn)死連接就一律用terminate。參數(shù)別拍腦袋。30秒的檢查間隔和60秒的容忍閾值適合絕大多數(shù)內(nèi)網(wǎng)和公網(wǎng)場(chǎng)景但如果你在弱網(wǎng)環(huán)境比如移動(dòng)端經(jīng)常進(jìn)出電梯建議把間隔調(diào)到15秒容忍閾值保持2個(gè)周期不變。間隔太短會(huì)增加無(wú)謂的包量和CPU開(kāi)銷(xiāo)太長(zhǎng)則會(huì)讓用戶(hù)感知到「已斷線(xiàn)但重連遲遲不來(lái)」。另外服務(wù)端terminate之后不要馬上重連——客戶(hù)端收到onclose再發(fā)起重連這才是合理鏈路服務(wù)端不要替客戶(hù)端做重連決定。參數(shù)建議值說(shuō)明HEARTBEAT_INTERVAL30s弱網(wǎng) 15s兩次 ping 的間隔HEARTBEAT_TIMEOUT2 × interval連續(xù)兩個(gè)周期無(wú) pong 判定死亡服務(wù)端斷開(kāi)方式terminate不依賴(lài) TCP 層狀態(tài)直接銷(xiāo)毀客戶(hù)端重連退避1s → 5s → 15s → 30s 封頂指數(shù)退避避免斷網(wǎng)恢復(fù)時(shí)打爆服務(wù)端3.3 瀏覽器端的取舍原生 ping/pong 不可控走應(yīng)用層心跳瀏覽器里的WebSocket API沒(méi)有暴露ping/pong的控制能力你拿不到底層的pong事件。所以網(wǎng)頁(yè)端通常退而求其次采用應(yīng)用層心跳前端定時(shí)發(fā)一條業(yè)務(wù)心跳服務(wù)端更新lastSeen并用服務(wù)端的定時(shí)掃描兜底。這不算違反協(xié)議層心跳原則而是平臺(tái)限制下的務(wù)實(shí)選擇。應(yīng)用層心跳的收發(fā)兩端格式要對(duì)齊我常駐的字段是{ type: heartbeat, ts: 1717300000000 }前端每25秒發(fā)一次比服務(wù)端30秒的判定窗口略短服務(wù)端收到后只更新時(shí)間戳不往業(yè)務(wù)消息隊(duì)列里塞。要注意應(yīng)用層心跳消息不要把數(shù)據(jù)寫(xiě)進(jìn)Redis之類(lèi)的存儲(chǔ)里否則線(xiàn)上幾十萬(wàn)連接每分鐘會(huì)產(chǎn)生幾百萬(wàn)次寫(xiě)入純屬浪費(fèi)。// 前端瀏覽器端心跳LAS 網(wǎng)頁(yè)端 const HEARTBEAT_APP_LEVEL 25_000; let heartbeatTimer null; function startHeartbeat(ws) { stopHeartbeat(); heartbeatTimer setInterval(() { if (ws.readyState WebSocket.OPEN) { ws.send(JSON.stringify({ type: heartbeat, ts: Date.now() })); } }, HEARTBEAT_APP_LEVEL); } function stopHeartbeat() { if (heartbeatTimer) clearInterval(heartbeatTimer); } // 頁(yè)面卸載時(shí)一定要清定時(shí)器否則頁(yè)面關(guān)了還在空發(fā) window.addEventListener(beforeunload, stopHeartbeat);前端還有一個(gè)容易被忽略的點(diǎn)onclose事件的延遲。網(wǎng)絡(luò)斷開(kāi)時(shí)瀏覽器不一定立刻觸發(fā)onclose可能需要幾十秒甚至更久。所以前端不能只依賴(lài)onclose來(lái)啟動(dòng)重連更穩(wěn)的做法是同時(shí)監(jiān)聽(tīng)onerror和onclose并在每次發(fā)送消息失敗時(shí)也觸發(fā)一次重連檢查。重連時(shí)要把連接重新注冊(cè)一遍這一點(diǎn)后面第5章會(huì)專(zhuān)門(mén)講它是最常見(jiàn)的掉線(xiàn)恢復(fù)翻車(chē)點(diǎn)。4. 多端消息的路由從 A 端發(fā)起到 B/C 端到達(dá)連接和心跳都就緒后核心業(yè)務(wù)邏輯才上場(chǎng)一條消息從某個(gè)端進(jìn)來(lái)服務(wù)端決定往哪幾個(gè)端轉(zhuǎn)發(fā)。這個(gè)章節(jié)說(shuō)的不是某個(gè)具體業(yè)務(wù)而是LAS多端互通里通用的消息分發(fā)骨架。協(xié)議定得好不好直接決定后面接多少個(gè)業(yè)務(wù)類(lèi)型都不慌。4.1 消息信封與消息類(lèi)型先定協(xié)議再寫(xiě)代碼我習(xí)慣給所有WebSocket消息統(tǒng)一包一個(gè)信封而不是各業(yè)務(wù)發(fā)各的裸JSON。信封字段如下字段類(lèi)型說(shuō)明msgIdstring全局唯一用于去重與回執(zhí)typestring業(yè)務(wù)類(lèi)型如 las.template.update / las.task.statusfromstring發(fā)送者 clientIdtostring目標(biāo)clientId / roomId / broadcastpayloadobject業(yè)務(wù)數(shù)據(jù)tsnumber客戶(hù)端時(shí)間戳這個(gè)信封的好處是路由層只認(rèn)msgId、type、to三個(gè)字段完全不用關(guān)心payload里的業(yè)務(wù)結(jié)構(gòu)。后面每接一個(gè)新業(yè)務(wù)只需要新增一個(gè)type路由邏輯一行不用改。LAS業(yè)務(wù)里我至少會(huì)分成三類(lèi)實(shí)時(shí)同步類(lèi)模板變更、狀態(tài)流轉(zhuǎn)、指令類(lèi)強(qiáng)制刷新、踢下線(xiàn)、文件類(lèi)二進(jìn)制分片。一個(gè)type字段就可以區(qū)分這些不要讓路由層靠識(shí)別payload里的字段名做判斷。4.2 路由與回執(zhí)目標(biāo)離線(xiàn)時(shí)消息怎么辦路由層要做的事是解析to然后到userMap或roomMap里查出目標(biāo)連接逐個(gè)發(fā)送。如果目標(biāo)端不在線(xiàn)LAS消息必須有個(gè)落地方案否則這條變更就丟了。離線(xiàn)消息的策略我推薦「Redis List暫存 登錄后主動(dòng)拉取」而不是服務(wù)端無(wú)限期給每個(gè)離線(xiàn)用戶(hù)堆消息。// router.js —— 消息分發(fā)與離線(xiàn)暫存假設(shè) Redis 已通過(guò) ioredis 初始化 async function dispatchMessage(raw) { const msg JSON.parse(raw); const { msgId, type, from, to } msg; const targets resolveTargets(to); let anyDelivered false; for (const connId of targets) { const ws connMap.get(connId); if (ws ws.readyState 1) { ws.send(JSON.stringify(msg)); anyDelivered true; } } if (!anyDelivered) { // 目標(biāo)連接全不在線(xiàn)按 clientId 維度暫存最近 50 條 const key las:offline:${to}; await redis.lpush(key, JSON.stringify(msg)); await redis.ltrim(key, 0, 49); // 只保留最新 50 條防止堆爆 await redis.expire(key, 7 * 24 * 3600); // 7 天有效期兜底 } return anyDelivered; }resolveTargets需要處理三種to值clientId就展開(kāi)成userMap里的Set roomId就展開(kāi)roomMapbroadcast就直接返回所有在線(xiàn)連接。注意anyDelivered只代表「發(fā)出去了」不代表對(duì)端業(yè)務(wù)處理成功。如果需要端到端確認(rèn)由對(duì)端回一條ack消息服務(wù)端再更新消息狀態(tài)。這個(gè)ack環(huán)節(jié)在LAS里很重要尤其是桌面端改模板后手機(jī)端必須確認(rèn)收到光靠「發(fā)出去了」是不夠的。還有一點(diǎn)ws.send在底層socket緩沖滿(mǎn)時(shí)可能拋出異常。大文件消息尤其常見(jiàn)需要在send外面包try/catchcatch到就用terminate處理這個(gè)連接別讓異常影響消息循環(huán)里的其他連接。4.3 去重與順序同一個(gè)用戶(hù)的多個(gè)端別互相打架一個(gè)用戶(hù)三個(gè)端同時(shí)在線(xiàn)的時(shí)候最容易出現(xiàn)兩類(lèi)問(wèn)題。第一類(lèi)是消息重復(fù)桌面端發(fā)起模板更新服務(wù)端廣播給三個(gè)端手機(jī)端和網(wǎng)頁(yè)端各收到一次前端如果都做了彈窗提示用戶(hù)會(huì)看到兩條一樣的信息。第二類(lèi)是順序錯(cuò)亂桌面端先發(fā)了「開(kāi)始同步」又發(fā)了「同步完成」但由于兩條消息走了不同的實(shí)例或線(xiàn)程服務(wù)端可能把后面那條先發(fā)出去。去重方案是在服務(wù)端維護(hù)一份msgId的最近緩存。每收一條消息就把msgId塞進(jìn)Redis的SET并設(shè)置過(guò)期時(shí)間比如10分鐘重復(fù)的msgId直接丟棄。注意這里去重的是「同一事件」而不是「同一事件的多次廣播」廣播給三個(gè)端是業(yè)務(wù)需要的不沖突。順序問(wèn)題更頭疼單實(shí)例里可用一個(gè)簡(jiǎn)單的自增seq保證同連接的消息有序多實(shí)例場(chǎng)景下需要讓同一個(gè)clientId的消息始終進(jìn)同一個(gè)消息隊(duì)列或分片才能?chē)?yán)格保序。對(duì)LAS這種實(shí)時(shí)協(xié)作場(chǎng)景我通常只在同一連接維度保序跨端全局強(qiáng)一致投入產(chǎn)出比不高。// dedup.js —— 最近 10 分鐘的 msgId 去重 async function isDuplicate(msgId) { const key las:msgdedup:${msgId}; // setnx 成功說(shuō)明第一次見(jiàn)失敗說(shuō)明重復(fù) const ok await redis.set(key, 1, EX, 600, NX); return !ok; }去重放在路由之前。收到消息先查重復(fù)再走dispatch。一個(gè)看似小但實(shí)際很關(guān)鍵的細(xì)節(jié)msgId的生成不能在服務(wù)端統(tǒng)一生成而要由發(fā)起端生成。原因很簡(jiǎn)單用戶(hù)可能在桌面端先發(fā)出了消息但因?yàn)榫W(wǎng)絡(luò)沒(méi)到達(dá)服務(wù)端隨后手機(jī)端又發(fā)起一次同樣操作如果msgId是服務(wù)端生成的這兩條消息永遠(yuǎn)無(wú)法被識(shí)別為同一條。5. 多端互通排查5 個(gè)常見(jiàn)坑與現(xiàn)場(chǎng)處理辦法WebSocket踩坑的路徑高度重復(fù)以下五條每一個(gè)我都實(shí)打?qū)嵱龅竭^(guò)現(xiàn)象、原因和解決辦法按順序?qū)懩憧梢詫?duì)照著手里的日志排查。5.1 Nginx 靜默掐斷空閑連接現(xiàn)象客戶(hù)端連接建立后隔一段時(shí)間恰好是60秒左右就收到onclose服務(wù)端日志里沒(méi)有任何close記錄。原因Nginx作為反向代理時(shí)默認(rèn)proxy_read_timeout是60秒在這段時(shí)間內(nèi)如果后端沒(méi)有數(shù)據(jù)返回Nginx會(huì)主動(dòng)斷開(kāi)連接。WebSocket的連接恰恰大部分時(shí)間沒(méi)有數(shù)據(jù)流動(dòng)于是被當(dāng)成空閑超時(shí)掐斷。解決在Nginx的location里顯式關(guān)閉代理超時(shí)。location /ws/ { proxy_pass http://las_ws_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }注意proxy_set_header Connection那行必須寫(xiě)成upgrade否則WebSocket握手在Nginx這一層就失敗。這個(gè)坑的癥狀是連得上但馬上斷開(kāi)和心跳無(wú)關(guān)。5.2 心跳間隔不一致導(dǎo)致誤殺現(xiàn)象客戶(hù)端明明在線(xiàn)卻頻繁被服務(wù)端斷線(xiàn)重連。原因服務(wù)端心跳判定閾值設(shè)的30秒客戶(hù)端的應(yīng)用層心跳發(fā)的倒是挺勤但客戶(hù)端所在的網(wǎng)絡(luò)環(huán)境有丟包pong幀偶爾沒(méi)回來(lái)連續(xù)兩個(gè)周期沒(méi)收到pong就被service端誤殺。解決把服務(wù)端的容忍閾值從2個(gè)周期放寬到3個(gè)周期同時(shí)讓客戶(hù)端的應(yīng)用層心跳間隔比服務(wù)端探活間隔短至少5秒留出余量。誤殺重連不是大事但每次誤殺都會(huì)帶來(lái)一次重連風(fēng)暴連接數(shù)多了會(huì)產(chǎn)生雪崩效應(yīng)這個(gè)參數(shù)值得多調(diào)幾輪。5.3 斷線(xiàn)重連后消息繼續(xù)發(fā)給舊連接現(xiàn)象用戶(hù)手機(jī)切了Wi-Fi再切回來(lái)連接斷了又重連成功但之后服務(wù)端發(fā)的消息他總是收不到。原因前端重連后只建立了新的TCP連接沒(méi)有重新發(fā)起注冊(cè)握手服務(wù)端userMap里用戶(hù)的connectionId還是舊的消息全發(fā)給了已經(jīng)死掉的舊連接。解決把「連接建立」和「連接注冊(cè)」做成兩個(gè)明確的階段前端必須在onopen之后等待注冊(cè)響應(yīng)服務(wù)端注冊(cè)成功再收業(yè)務(wù)消息。最常見(jiàn)做法是重連后第一條消息一定是register。// 客戶(hù)端重連后必須重新 register不能只 new WebSocket() function connectWithRegister() { const ws new WebSocket(wss://las.example.com/ws?clientIdU10086); ws.onopen () { ws.send(JSON.stringify({ type: register, clientId: U10086 })); }; }服務(wù)端把register消息放進(jìn)用戶(hù)白名單沒(méi)注冊(cè)的連接拒絕轉(zhuǎn)發(fā)業(yè)務(wù)消息。這個(gè)約束能直接避免重連后消息丟失的黑匣子問(wèn)題。5.4 多端在線(xiàn)時(shí)的消息重復(fù)與回顯問(wèn)題現(xiàn)象A端發(fā)一條消息B端、C端都收到了但A端自己也收到了一份服務(wù)端回顯前端沒(méi)有過(guò)濾界面上出現(xiàn)兩條自己發(fā)的消息。原因廣播邏輯沒(méi)有排除發(fā)送者連接或者前端沒(méi)有對(duì)本地發(fā)送的消息做ack去重。解決服務(wù)端廣播時(shí)排除from的connId前端也最好把「自己發(fā)出的消息」直接渲染成pending狀態(tài)收到ack再變成已送達(dá)而不是等廣播回來(lái)再渲染。LAS里桌面端和網(wǎng)頁(yè)端經(jīng)常共用一個(gè)賬號(hào)回顯去重尤其要注意。5.5 Sending on closed socket 異?，F(xiàn)象服務(wù)端日志頻繁出現(xiàn)Error: Sending on closed socket偶發(fā)進(jìn)程崩潰。原因連接在ws.send之前剛被關(guān)閉但connMap里還殘留引用代碼直接往已關(guān)閉的連接上寫(xiě)數(shù)據(jù)。解決發(fā)消息前檢查readyState 1只是第一道保險(xiǎn)還要在send外面包try/catchcatch住就直接清理連接索引。不要小看這個(gè)錯(cuò)誤流量高峰時(shí)它會(huì)拖垮整個(gè)消息循環(huán)屬于高發(fā)事故源。// safeSend.ts —— 帶兜底的發(fā)送封裝 function safeSend(ws, raw) { try { if (ws ws.readyState 1) ws.send(raw); } catch (e) { // 連接已死清索引并終止 connMap.delete(ws.connId); ws.terminate(); } }6. 進(jìn)階多實(shí)例擴(kuò)展與端到端驗(yàn)證單機(jī)跑通只是開(kāi)始LAS多端互通要上生產(chǎn)單實(shí)例撐不住所有在線(xiàn)連接橫向擴(kuò)展是繞不開(kāi)的問(wèn)題。一個(gè)用戶(hù)連在實(shí)例A另一個(gè)用戶(hù)連在實(shí)例B兩個(gè)實(shí)例之間的連接互相不知道對(duì)方消息就斷在中間。常見(jiàn)做法是引入Redis Pub/Sub作為實(shí)例間消息總線(xiàn)本地路由直接發(fā)本機(jī)連接跨實(shí)例消息通過(guò)Redis發(fā)布所有實(shí)例都訂閱同一個(gè)頻道收到后檢查目標(biāo)連接是否在自己這里。// cluster.js —— 多實(shí)例橋接本地直接路由跨實(shí)例走 Redis 廣播 const sub new Redis(); // 訂閱連接 const pub new Redis(); // 發(fā)布連接 sub.subscribe(las:ws:cluster); sub.on(message, (_channel, raw) { const envelope JSON.parse(raw); // 只有目標(biāo)連接在本實(shí)例才處理避免 A 實(shí)例收到又轉(zhuǎn)發(fā)回 B 實(shí)例 dispatchMessage(envelope); }); function sendCrossInstance(targetConnId, msg) { pub.publish(las:ws:cluster, JSON.stringify({ target: targetConnId, msg })); }端到端驗(yàn)證我習(xí)慣用Node腳本模擬多端同時(shí)在線(xiàn)而不是靠手工開(kāi)幾個(gè)瀏覽器窗口戳來(lái)戳去。用ws庫(kù)起一個(gè)測(cè)試客戶(hù)端同時(shí)模擬桌面端、網(wǎng)頁(yè)端、手機(jī)端三個(gè)身份連到同一個(gè)clientId下然后讓一端發(fā)消息斷言另外兩端都能收到再手動(dòng)調(diào)低心跳閾值驗(yàn)證斷線(xiàn)重連。// test.js —— 模擬 100 個(gè)并發(fā)端做聯(lián)調(diào) const WebSocket require(ws); function createTestClient(clientId, port 8080) { const ws new WebSocket(ws://127.0.0.1:${port}/ws?clientId${clientId}); ws.on(message, (data) { const msg JSON.parse(data.toString()); if (msg.type las.template.update) { console.log([${clientId}] 收到模板更新:, msg.payload.version); } }); return ws; } // 同時(shí)模擬 100 個(gè)用戶(hù)在線(xiàn) const clients Array.from({ length: 100 }, (_, i) createTestClient(U${10000 i}) ); // 等 2 秒連接全部建立再?gòu)?U10000 廣播一條模板更新 setTimeout(() { clients[0].send(JSON.stringify({ type: las.template.update, to: broadcast, payload: { version: v2.3.1 } })); }, 2000);跑這個(gè)腳本時(shí)重點(diǎn)觀察兩個(gè)指標(biāo)一是100個(gè)連接同時(shí)注冊(cè)時(shí)服務(wù)端有沒(méi)有內(nèi)存突增或報(bào)錯(cuò)二是廣播后是否每個(gè)端都收到了且只收到一次——重復(fù)也說(shuō)明路由有問(wèn)題。我自己的教訓(xùn)是多端互通上線(xiàn)前一定要專(zhuān)門(mén)做一次「殺掉服務(wù)端」的演練看客戶(hù)端重連能不能在30秒內(nèi)全部恢復(fù)賬號(hào)信息會(huì)不會(huì)因?yàn)橹剡B而丟。這個(gè)演練花錢(qián)最少、救急最多。LAS多端互通的實(shí)現(xiàn)鏈條就是這樣連接注冊(cè)、心跳判定、消息路由、多實(shí)例橋接每層都守住邊界端和端之間才能安靜地實(shí)時(shí)同步。希望這些踩出來(lái)的經(jīng)驗(yàn)幫到你。本文還有配套的精品資源點(diǎn)擊獲取