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