聊到“PHP 實時聊天室源碼 WebSocket”這個標(biāo)題我估計不少人腦子里第一時間冒出來的問題是PHP 不是處理請求就退出嗎它怎么做長連接怎么實時推消息這問題我當(dāng)年也問過自己。先說結(jié)論P(yáng)HP 完全可以做 WebSocket 服務(wù)端關(guān)鍵是你得跳出“每次請求跑完就結(jié)束”的思維定式進(jìn)入“常駐內(nèi)存 事件回調(diào)”的模式。這篇文章會把這個項目的原理、服務(wù)端源碼、前端對接、部署和排錯全部拆開講適合那種已經(jīng)會寫 PHP 增刪改查、但第一次接觸長連接實時通信的開發(fā)者看。我自己做這個聊天室項目時一開始也迷信過“AJAX 輪詢”這種老路子后來被現(xiàn)實教育之后才徹底轉(zhuǎn)向 WebSocket。為了讓你少走彎路我會把踩過的坑、調(diào)過的參數(shù)、驗證過的思路都寫出來。放心不是那種貼一段代碼就跑的教程而是真正能落到生產(chǎn)環(huán)境的東西。1. 先把問題想清楚HTTP 輪詢到底卡在哪1.1 輪詢的痛點(diǎn)和長連接的出現(xiàn)聊 WebSocket 之前得先明白它解決了什么問題。傳統(tǒng)的 HTTP 請求是“客戶端問、服務(wù)端答”一問一答之后連接基本就斷了。聊天室要求服務(wù)端把消息主動推給所有在線的人這就跟 HTTP 的模型擰著來。早年大家用輪詢硬撐前端每隔一秒發(fā)一個 AJAX 請求問“有沒有新消息”服務(wù)端查一下數(shù)據(jù)庫再返回。消息少的時候還能用用戶一多每個在線用戶每秒都來請求服務(wù)器壓力成倍往上翻。我當(dāng)時測試 50 個人在線一臺低配服務(wù)器就被打滿了而且輪到別人的消息要想被新進(jìn)來的人看到還得額外做補(bǔ)償查詢邏輯越添越亂。輪詢的本質(zhì)問題是“拉”而不是“推”服務(wù)端不知道用戶什么時候走開客戶端也不知道服務(wù)端什么時候有貨兩邊都靠頻繁試探來碰運(yùn)氣。更麻煩的是實時性沒法保證一秒輪詢一次高峰期排隊的請求多了消息延遲能到兩三秒這對聊天場景來說基本不能用。長連接方案的核心思路是連接建立后不馬上斷開服務(wù)端可以隨時往這條連接里寫數(shù)據(jù)客戶端也可以隨時發(fā)數(shù)據(jù)雙方都處于“隨時可以說話”的狀態(tài)。這就是 WebSocket 解決的痛點(diǎn)。1.2 WebSocket、SSE、輪詢到底選誰很多人只聽說過 WebSocket但實際做實時推送時還有“SSE服務(wù)器發(fā)送事件”這個選項它跟 WebSocket 理念很像但走的還是 HTTP 協(xié)議。幾個方案放一起對比會更直觀方案連接方式服務(wù)端推消息瀏覽器兼容性適用場景短輪詢每隔一段時間發(fā)普通 HTTP 請求不支持主動推靠客戶端反復(fù)問全兼容消息頻率極低的管理后臺長輪詢請求掛住服務(wù)端有數(shù)據(jù)再返回勉強(qiáng)算半推半拉其實還是請求-響應(yīng)全兼容兼容性要求極高且并發(fā)不大的場景SSE一條 HTTP 長連接服務(wù)端單向?qū)懼С值荒芊?wù)端推給客戶端現(xiàn)代瀏覽器均可老 Edge 不支持服務(wù)端推送通知、股價行情等單向場景WebSocket獨(dú)立的全雙工長連接支持客戶端和服務(wù)端雙向推現(xiàn)代瀏覽器全覆蓋聊天、協(xié)同編輯、實時互動游戲聊天室天然是雙向的你要發(fā)消息給別人也要接收別人的消息所以 WebSocket 是最合適的選擇沒有之一。它在建立連接時用的是 HTTP 的握手握手成功后協(xié)議升級后續(xù)數(shù)據(jù)幀不再走 HTTP 報文而是走長度小得多的 WebSocket 數(shù)據(jù)幀省掉了大量 HTTP 頭部開銷這也是它能承載高頻率消息的原因之一。1.3 聊天室項目的核心技術(shù)挑戰(zhàn)這個項目的標(biāo)題看著簡單真做起來有幾道坎。第一道坎是“連接管理”“在線的連接放哪、掉線了怎么清理、同一用戶多端登錄怎么處理”。第二道坎是“消息分發(fā)”一條消息怎么高效地發(fā)給所有人而不是寫個 for 循環(huán)一個個 push 導(dǎo)致同步阻塞。第三道坎是“穩(wěn)定性”長連接掛幾個小時是常態(tài)內(nèi)存泄露、fd 泄漏、心跳失聯(lián)任何一個沒處理好服務(wù)跑兩三天就崩。我在做這個項目時光心跳機(jī)制就調(diào)整了三個版本后面會專門拆開講。2. 技術(shù)選型為什么 PHP 也能擔(dān)起實時通信的活2.1 核心認(rèn)知PHP 的常駐內(nèi)存模式傳統(tǒng) PHP 開發(fā)中PHP-FPM 模式下每個請求進(jìn)來腳本從頭到尾執(zhí)行一遍執(zhí)行完所有變量、連接、資源全部釋放這叫“生命周期隨請求結(jié)束”。WebSocket 服務(wù)端得 7x24 小時運(yùn)行連接建立后要一直在內(nèi)存里等消息所以你要用的不是 PHP-FPM 那一套而是“常駐內(nèi)存模式”PHP 進(jìn)程啟動后初始化一次然后進(jìn)入事件循環(huán)不斷處理新連接、新消息、斷開事件直到進(jìn)程被手動停止或崩潰重啟。用生活化的類比來說PHP-FPM 像是銀行柜臺每個客戶來了臨時開個窗口辦業(yè)務(wù)辦完關(guān)窗而常駐模式像是呼叫中心坐席一直坐在工位上等電話進(jìn)來電話進(jìn)來就接掛了繼續(xù)等下一個。做 WebSocket 服務(wù)端你需要的就是后者。目前實現(xiàn)方式主要有兩類一類是事件驅(qū)動框架把底層的輪詢與網(wǎng)絡(luò)事件封裝好你在回調(diào)里寫業(yè)務(wù)另一類是直接用擴(kuò)展提供的原生接口。方式不同事件模型的核心思想是一致的。實現(xiàn)時只需要安裝好對應(yīng)擴(kuò)展并確認(rèn) CLI 模式可用。服務(wù)端代碼以 CLI 方式啟動而不是跑在 Web 目錄下這點(diǎn)新手最容易搞混——把 WebSocket 服務(wù)端代碼當(dāng)普通 PHP 文件丟進(jìn) Apache然后訪問它當(dāng)然什么都不會發(fā)生。2.2 一個能跑的 WebSocket 服務(wù)需要哪些零件拆開看一個最小可用的 PHP WebSocket 服務(wù)端包含這么幾個部件網(wǎng)絡(luò)服務(wù)器監(jiān)聽端口接受 TCP 連接完成 WebSocket 握手協(xié)議。事件循環(huán)監(jiān)聽客戶端連接上的數(shù)據(jù)到達(dá)、斷開等事件并回調(diào)業(yè)務(wù)邏輯。連接表記錄每個連接的唯一標(biāo)識fd即文件描述符、用戶信息用適當(dāng)?shù)娜萜鞔嫫饋?。協(xié)議處理器解析 WebSocket 數(shù)據(jù)幀因為客戶端發(fā)來的數(shù)據(jù)是分幀的可能拆包、粘包需要按協(xié)議重組。業(yè)務(wù)回調(diào)對外暴露“連接打開”“收到消息”“連接關(guān)閉”等事件供我們填充聊天邏輯。這些零件如果全從零手寫光數(shù)據(jù)幀的掩碼處理和分片重組就夠折騰一天。所以我強(qiáng)烈建議直接用成熟框架的封裝只關(guān)注業(yè)務(wù)回調(diào)部分。PHP 生態(tài)里成熟的長連接框架已經(jīng)幫你把這些底層細(xì)節(jié)處理得很干凈你寫的代碼量會少一個量級而且踩坑概率低很多。2.3 項目架構(gòu)總覽與數(shù)據(jù)流我最終采用的結(jié)構(gòu)是前端瀏覽器 → Nginx負(fù)責(zé)靜態(tài)資源和反向代理→ WebSocket 服務(wù)端PHP 常駐進(jìn)程→ 可選的 Redis多機(jī)擴(kuò)展時做消息中轉(zhuǎn)。數(shù)據(jù)流走兩段。第一條路徑是“用戶進(jìn)入聊天室”瀏覽器發(fā)起 WebSocket 連接Nginx 把帶有 Upgrade 頭的請求轉(zhuǎn)發(fā)給 PHP 服務(wù)端PHP 完成握手后觸發(fā) Open 回調(diào)此時把連接記錄到連接表并廣播“某某進(jìn)入了聊天室”。第二條路徑是“消息傳播”用戶 A 在頁面輸入文字前端把消息包裝成 JSON 通過 WebSocket 發(fā)送PHP 服務(wù)端收到后觸發(fā) Message 回調(diào)對這個 JSON 做解析和校驗然后遍歷連接表把消息廣播給所有在線連接包括排除發(fā)送者自己或者包含發(fā)送者看產(chǎn)品需要。如果用戶 A 發(fā)的是私聊則只推給目標(biāo) fd。整個過程用的是 TCP 長連接消息實時性幾乎無延遲。這個架構(gòu)的好處是簡潔、單機(jī)就能跑。等用戶量大了單機(jī)進(jìn)程扛不住再把“遍歷連接表廣播”改成“推給 Redis 頻道多臺機(jī)器訂閱同一個頻道分別推送給自己機(jī)器上的用戶”這部分我在后面部署章節(jié)展開講。3. 原理先行WebSocket 握手和 PHP 事件回調(diào)3.1 一次完整的握手從 Upgrade 到 101WebSocket 建立連接并不是直接拉起一條神秘通道而是先走一次 HTTP 握手。客戶端發(fā)個特殊格式的請求服務(wù)端確認(rèn)后返回 101 狀態(tài)碼協(xié)議才算切換成功。正常瀏覽器會自動完成握手但在調(diào)試時你得能看懂這個過程?？蛻舳税l(fā)起握手時請求頭長這樣GET /chat HTTP/1.1 Host: your-domain.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13 Origin: http://your-domain.com其中Sec-WebSocket-Key是客戶端生成的隨機(jī) Base64 字符串用它來防止代理緩存導(dǎo)致的連接復(fù)用。服務(wù)端收到后把這個 Key 拼上一個固定的 GUID 字符串協(xié)議規(guī)定好的258EAFA5-E914-47DA-95CA-C5AB0DC85B11做一次 SHA1 散列再 Base64 編碼作為Sec-WebSocket-Accept返回。服務(wù)端的響應(yīng)頭長這樣HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbKxOo拿到這個 101 響應(yīng)之后連接正式切換為 WebSocket 協(xié)議。這之后傳輸?shù)臄?shù)據(jù)就是二進(jìn)制數(shù)據(jù)幀或文本幀不再有 HTTP 頭那一大堆冗余信息。了解握手過程有什么實際價值呢排錯時非常有價值。比如你看到客戶端報Unexpected response code: 200說明請求沒有打到 WebSocket 服務(wù)端而是被某個中間層攔截并當(dāng)普通 HTTP 請求處理了這通常是 Nginx 沒配好Upgrade頭導(dǎo)致的排查方向一下子就能確定。3.2 連接生命周期Open、Message、Close框架的封裝方式一般會暴露三個核心事件連接打開Open、收到消息Message、連接關(guān)閉Close。這三個事件覆蓋了一條 WebSocket 連接從生到死的完整生命周期。Open 事件在握手成功后觸發(fā)此時可以拿到客戶端信息比如來源 IP、請求頭、URL 參數(shù)。在這里做的典型事情是生成連接唯一標(biāo)識、把它加入連接池、標(biāo)記連接建立時間。需要注意一點(diǎn)不要在 Open 里做耗時操作比如查數(shù)據(jù)庫、請求外部接口因為事件循環(huán)是單線程的某個回調(diào)卡住了其他所有連接的消息都會跟著排隊等待。Message 事件是業(yè)務(wù)核心收到消息后要解析協(xié)議我們約定 JSON、校驗數(shù)據(jù)合法性、執(zhí)行邏輯存庫、廣播、私聊。Close 事件在連接斷開時觸發(fā)這里必須清理連接表里的殘留數(shù)據(jù)。很多人忽略 Close 的重要性結(jié)果用戶下線了連接表里還留著臟數(shù)據(jù)廣播時給一個已經(jīng)斷開的 fd 推送報錯不說還白白浪費(fèi)資源。還有一類隱藏事件是“連接異常中斷”比如客戶端直接拔網(wǎng)線、斷電TCP 層可能不會立即感知服務(wù)端這個連接會一直掛在連接表里。這種情況一般靠心跳超時兜底后面專門講。3.3 消息廣播模型誰負(fù)責(zé)把話帶給所有人單機(jī)場景下廣播的樸素寫法是收到一條消息后循環(huán)所有在線 fd逐個 push。這個思路沒錯但它有兩個坑。第一如果某個客戶端接收緩沖已滿比如網(wǎng)速極慢消息堆積push 操作可能會阻塞拖慢整個事件循環(huán)。第二如果在線人數(shù)上千循環(huán)一千次雖然不快但每次都做 JSON 編碼、協(xié)議組裝高頻消息下 CPU 開銷還是能疊上去。我的做法是廣播前先做一次“可達(dá)性檢查”只維護(hù)一個在線連接表記錄每個 fd 的最近活躍時間心跳超時的先剔除再廣播。這樣廣播的循環(huán)對象永遠(yuǎn)是“大概率還活著的連接”穩(wěn)定性好很多。至于高并發(fā)下的優(yōu)化一般框架會支持分批發(fā)送與緩沖控制底層細(xì)節(jié)框架已經(jīng)處理。你只需要理解模型WebSocket 服務(wù)端天然是“中央分發(fā)器”所有消息都經(jīng)它中轉(zhuǎn)它既是服務(wù)器又是路由器。這也是為什么聊天室的瓶頸總會出現(xiàn)在消息分發(fā)層而不是數(shù)據(jù)庫層。4. 實操落地從零搭一個能用的實時聊天室4.1 服務(wù)端連接管理 登錄 廣播現(xiàn)在進(jìn)入正題。我以事件驅(qū)動模型為例寫服務(wù)端代碼框架名不重要重點(diǎn)是回調(diào)里寫的這套業(yè)務(wù)邏輯你換到同類框架上也完全適用。先定義全局狀態(tài)連接表$fdToUser映射 fd 到用戶名$userToFd映射用戶名到 fd。雙映射的好處是收到廣播需求時按 fd 遍歷收到私聊需求時按名字查 fd用戶退出時兩邊都能干凈地清理。代碼如下?php // 全局連接狀態(tài) $fdToUser []; // fd username $userToFd []; // username fd // 連接打開先記錄基本狀態(tài)但此時還沒登錄 $wsServer-on(Open, function ($server, $request) { echo 新連接進(jìn)入fd{$request-fd}\n; }); // 收到消息按約定的 JSON 協(xié)議分發(fā)處理 $wsServer-on(Message, function ($server, $frame) use ($fdToUser, $userToFd) { $fd $frame-fd; $payload json_decode($frame-data, true); if (!is_array($payload)) { return; // 非法報文直接丟棄 } switch ($payload[type] ?? ) { case login: handleLogin($server, $fd, $payload, $fdToUser, $userToFd); break; case chat: handleChat($server, $fd, $payload, $fdToUser); break; case ping: // 心跳包只需要回一個 pong不廣播 $server-push($fd, json_encode([type pong])); break; } }); function handleLogin($server, $fd, $payload, $fdToUser, $userToFd) { $username trim($payload[username] ?? ); if ($username || isset($userToFd[$username])) { $server-push($fd, json_encode([ type error, message 昵稱無效或已被占用 ])); $server-close($fd); return; } $fdToUser[$fd] $username; $userToFd[$username] $fd; // 告訴所有人有人進(jìn)來了 broadcast($server, [ type system, message {$username} 加入了聊天室, online count($userToFd) ]); } function handleChat($server, $fd, $payload, $fdToUser) { $username $fdToUser[$fd] ?? ; $content trim($payload[content] ?? ); if ($username || $content ) { return; } // 簡單校驗長度防止有人拿超長文刷屏 if (mb_strlen($content) 500) { $server-push($fd, json_encode([ type error, message 消息長度不能超過 500 字 ])); return; } broadcast($server, [ type chat, from $username, content $content, time date(H:i:s) ]); } // 廣播排除指定 fd默認(rèn)排除發(fā)送者自己 function broadcast($server, $data, $exceptFd null, $fdToUser null) { $message json_encode($data, JSON_UNESCAPED_UNICODE); foreach ($fdToUser as $targetFd $u) { if ($exceptFd ! null $targetFd $exceptFd) { continue; } if ($server-isEstablished($targetFd)) { $server-push($targetFd, $message); } } }這些代碼里的幾個細(xì)節(jié)值得單獨(dú)說。登錄失敗我直接close了連接而不是只回一個錯誤原因是連接沒登錄就閑置著既不參與聊天也不觸發(fā)心跳清理很容易變成僵尸連接直接關(guān)閉更干凈。消息長度限制很多人不做但聊天室是最容易被刷屏攻擊的場景一個 10MB 的消息如果廣播給所有人服務(wù)端內(nèi)存瞬間暴漲所以限制長度不是體驗問題是安全問題。4.2 服務(wù)端私聊與“正在輸入”狀態(tài)公共聊天室能跑起來之后用戶很快就會想要私聊。私聊的邏輯其實比廣播還簡單根據(jù)目標(biāo)用戶名從$userToFd查到 fd只推給對方就行。這里有個邊界要注意目標(biāo)用戶不在線時可以給發(fā)送者回一條“對方不在線”的系統(tǒng)消息也可以把消息暫存到 Redis等對方上線再拉取。我第一版沒做離線暫存后來發(fā)現(xiàn)用戶經(jīng)常問“我發(fā)給他的消息他怎么沒收到”第二版加了 Redis 離線消息隊列體驗才正常?！罢谳斎搿睜顟B(tài)是另一個容易被忽略的高頻功能。實現(xiàn)方式是前端監(jiān)聽到用戶在輸入框打字就發(fā)一個type: typing的包服務(wù)端收到后轉(zhuǎn)發(fā)給房間里的其他人其他人展示“某某正在輸入”。這里必須加上限流不然每敲一個字符發(fā)一次消息量會非常大。我用的策略是同一個用戶兩次typing包的間隔不低于 2 秒低于間隔的包直接丟棄同時前端 2 秒沒再輸入就發(fā)一個type: stop_typing清除狀態(tài)。這樣既保住了實時感又不會把服務(wù)端壓垮。case typing: $username $fdToUser[$fd] ?? ; if ($username ) return; // 用當(dāng)前時間做簡單限流 if (time() - ($lastTypingTime[$username] ?? 0) 2) return; $lastTypingTime[$username] time(); broadcast($server, [ type typing, from $username ], null, $fdToUser); break;這個$lastTypingTime數(shù)組會隨著時間不斷變大你得定期清理掉已經(jīng)離線的用戶名否則又是內(nèi)存泄露。常見的做法是復(fù)用 Close 事件在用戶退出時把它的lastTypingTime一并刪掉。4.3 前端WebSocket 客戶端與心跳重連前端代碼也不復(fù)雜但容易寫漏。一個健壯的客戶端必須包含三塊建立連接、心跳保活、斷線重連。// chat-client.js let ws null; let heartbeatTimer null; let reconnectCount 0; function connect() { ws new WebSocket(ws://your-domain.com/chat); ws.onopen function () { console.log(連接已建立); reconnectCount 0; // 登錄 ws.send(JSON.stringify({ type: login, username: currentUsername })); // 開啟心跳每 30 秒發(fā)一次 ping heartbeatTimer setInterval(function () { if (ws.readyState WebSocket.OPEN) { ws.send(JSON.stringify({ type: ping })); } }, 30000); }; ws.onmessage function (event) { const data JSON.parse(event.data); if (data.type chat) { renderMessage(data); } else if (data.type system) { renderSystemMessage(data.message, data.online); } else if (data.type typing) { showTyping(data.from); } else if (data.type pong) { // 心跳回包什么都不用做 } }; ws.onclose function () { clearInterval(heartbeatTimer); // 指數(shù)退避重連 const delay Math.min(30000, 1000 * Math.pow(2, reconnectCount)); reconnectCount; setTimeout(connect, delay); }; ws.onerror function () { // 觸發(fā) onclose做統(tǒng)一處理 ws.close(); }; } connect();重連這個細(xì)節(jié)我要多說一句不要用固定 3 秒重連如果服務(wù)端重啟需要一分鐘客戶端在這段時間內(nèi)每 3 秒瘋狂重連一次服務(wù)端一恢復(fù)就會收到幾十個連接請求很容易被打懵。指數(shù)退避重連是標(biāo)準(zhǔn)做法第一次 1 秒、第二次 2 秒、第三次 4 秒封頂 30 秒重連成功后重置計數(shù)。這個策略是我在項目上線后遇到“服務(wù)重啟后大量連接同時涌入”的問題才加上的加完之后重啟服務(wù)再也沒出過問題。心跳時間間隔的選擇也有講究太短浪費(fèi)帶寬太長容易導(dǎo)致連接被中間層斷開。我的經(jīng)驗是前端 30 秒發(fā)一次 ping服務(wù)端 60 秒內(nèi)沒收到任何數(shù)據(jù)就主動關(guān)閉該連接。這個“服務(wù)端超時比客戶端心跳周期長一倍”的配置能保證正常用戶永遠(yuǎn)不被誤殺又能在網(wǎng)絡(luò)異常時及時清理僵尸連接。4.4 前端消息渲染與性能消息渲染這塊新手常犯的錯誤是把所有歷史消息都渲染在 DOM 里。聊天室里消息會無限增長幾千條 DOM 節(jié)點(diǎn)之后頁面會明顯變卡。我第一版就是 push 一條渲染一條聊了半小時后整個頁面滾動都掉幀。后來改成只保留最近 100 條 DOM 節(jié)點(diǎn)超過 100 條就把最老的從 DOM 中移除歷史消息從服務(wù)端接口按需加載。這個改動對頁面流暢度的提升非常明顯。渲染時還有一個安全問題必須處理消息內(nèi)容是用戶輸入的原始文本直接拼進(jìn)innerHTML等于把 XSS 漏洞親手打開。我的做法是所有聊天內(nèi)容渲染時都用textContent而不是innerHTML如果確實需要支持表情和鏈接也要先做轉(zhuǎn)義只放行白名單標(biāo)簽。這個項目里我甚至為了保險做了兩層校驗前端渲染時轉(zhuǎn)義服務(wù)端存儲時也轉(zhuǎn)義一遍。5. 部署與擴(kuò)展從單機(jī)到多機(jī)的實戰(zhàn)經(jīng)驗5.1 Nginx 反向代理 WebSocket 的配置要點(diǎn)本地跑通之后部署到服務(wù)器時大概率會遇到第一個門檻怎么讓 Nginx 把 WebSocket 流量轉(zhuǎn)發(fā)到 PHP 服務(wù)端。直接暴露 WebSocket 端口給公網(wǎng)不是不行但你會失去 SSL、限流、日志這些能力而且 80/443 之外的高端口在防火墻上還要多開規(guī)則。所以標(biāo)準(zhǔn)做法是 Nginx 反向代理。server { listen 443 ssl; server_name your-domain.com; # SSL 證書配置省略 location /chat { proxy_pass http://127.0.0.1:9502; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_read_timeout 3600s; proxy_send_timeout 3600s; } }這個配置里最關(guān)鍵的就是proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection upgrade;。少了這兩行Nginx 默認(rèn)會用 HTTP/1.0 轉(zhuǎn)發(fā)請求WebSocket 握手必然失敗前端會報 400 或 200 錯誤。另外proxy_read_timeout默認(rèn)是 60 秒如果服務(wù)端和客戶端之間的空閑時間超過這個值Nginx 會自作主張把長連接掐斷。因為我們的客戶端每 30 秒有心跳理論上游永遠(yuǎn)不會超時但為了保險我把它設(shè)成了 3600 秒防止客戶端心跳邏輯意外失效時連接被提前斷開。5.2 多機(jī)部署Redis 發(fā)布訂閱做消息中轉(zhuǎn)單機(jī)能支撐的連接數(shù)取決于機(jī)器性能一般幾千連接是沒問題的但再往上就想也別想了。當(dāng)你需要拆成兩臺、三臺機(jī)器時最樸素的做法會立刻遇到一個問題用戶 A 連在機(jī)器 1 上用戶 B 連在機(jī)器 2 上A 發(fā)的消息只在機(jī)器 1 的進(jìn)程里廣播B 永遠(yuǎn)收不到。解法是用 Redis 發(fā)布訂閱做消息總線。機(jī)器 1 收到消息后除了廣播給本機(jī)的連接還把消息publish到 Redis 的一個固定頻道機(jī)器 2、機(jī)器 3 都在訂閱這個頻道收到后各自廣播給本機(jī)的連接。這樣消息就能跨機(jī)器傳播。架構(gòu)變成用戶 A → 機(jī)器1 WebSocket 服務(wù) → publish Redis 頻道 ↓ 訂閱 用戶 B ← 機(jī)器2 WebSocket 服務(wù) ← 收到頻道消息后廣播這個方案的優(yōu)點(diǎn)是不需要維護(hù)一個中心化的連接表每臺機(jī)器只管自己的連接缺點(diǎn)是消息至少經(jīng)過一次 Redis 轉(zhuǎn)發(fā)延遲多一跳實測局域網(wǎng)內(nèi)增加不到 1 毫秒完全可以接受。我實際部署時用的是兩臺機(jī)器加一個 Redis用戶分布不均——有人全擠在機(jī)器 1 上但跨機(jī)消息依然正常這個方案就夠用了。如果以后用戶量再上一個量級需要更精細(xì)的路由、離線消息、消息序號那就得引入專業(yè)的消息中間件來負(fù)責(zé)廣播路由但那是另一個量級的復(fù)雜度了這里不展開。5.3 性能與內(nèi)存長連接服務(wù)最容易被忽視的坑WebSocket 服務(wù)和傳統(tǒng) PHP 項目最大的不同是進(jìn)程不退出所以每一處內(nèi)存使用都要自己負(fù)責(zé)。我列舉幾個我實際踩過的內(nèi)存相關(guān)坑希望能幫你提前避開。第一個是日志無腦打印。開發(fā)時在 Message 回調(diào)里echo每個消息沒問題生產(chǎn)環(huán)境如果還開著詳細(xì)日志每個聊天消息都會觸發(fā)磁盤寫入高頻消息下進(jìn)程直接卡頓。上線時把日志級別調(diào)到“連接建立、連接關(guān)閉、異常”這個粒度業(yè)務(wù)消息不落日志需要排查時再臨時開。第二個是數(shù)組無限增長。連接表和lastTypingTime這類緩存數(shù)組如果不在 Close 事件里清理跑幾天內(nèi)存就爆了。這個在 4.2 節(jié)已經(jīng)強(qiáng)調(diào)過但值得再說一遍所有全局狀態(tài)都必須有對應(yīng)的清理路徑。第三個是單條消息大小限制。消息內(nèi)容如果不限制惡意客戶端可以一次發(fā) 1GB 文本服務(wù)端解碼就會內(nèi)存爆炸。服務(wù)端在Message回調(diào)入口就要檢查frame-data的長度超過閾值直接斷開連接不給后續(xù)邏輯處理的機(jī)會。性能方面的另一個建議是如果服務(wù)器有多核 CPU單進(jìn)程只能吃滿一個核想提升單機(jī)吞吐就得多進(jìn)程部署每個進(jìn)程綁定一個 CPU 核。但多進(jìn)程帶來的問題是不同進(jìn)程的連接表互相隔離廣播時不知道別的進(jìn)程有哪些連接。解決方式是要么用 Redis 做多進(jìn)程間的消息同步要么用框架自帶的進(jìn)程間通信能力。如果對這塊不熟先老老實實單進(jìn)程跑撐不住再上多進(jìn)程。6. 常見問題與排查技巧實錄6.1 連接總是三秒斷心跳和代理超時我接手過一個同事的項目現(xiàn)象是客戶端連上后大約 60 秒必斷重連之后又是 60 秒斷非常有規(guī)律。排查了半天發(fā)現(xiàn)是 Nginx 沒有配proxy_read_timeout默認(rèn) 60 秒超時而客戶端的心跳邏輯寫得有問題只在onopen之后瞬間發(fā)了一次心跳后面就不再發(fā)了。服務(wù)端那邊也沒做超時清理兩邊都以為自己是“被動方”結(jié)果 Nginx 先動手把連接掐了。定位這種問題的方法是看抓包。WebSocket 的調(diào)試不用抓包工具也能做瀏覽器開發(fā)者工具的 Network 面板里能看到 WebSocket 幀Nginx 的 error.log 里也會留下upstream timed out或client closed connection之類的記錄。解決思路是客戶端確認(rèn)心跳周期小于任何一層代理的超時時間服務(wù)端確認(rèn)自己會按期響應(yīng)心跳Nginx 確認(rèn)超時時間遠(yuǎn)大于心跳周期。三端對齊斷連問題基本根治。6.2 消息丟失與亂序消息丟失最常見的原因是“發(fā)送時連接已斷開但代碼沒檢查”。你在handleChat里拿到$fd后如果對端已經(jīng)斷了push調(diào)用會拋異?；蚍祷厥∪绻a沒處理消息就悄悄丟了。標(biāo)準(zhǔn)做法是每次 push 前檢查isEstablishedpush 后檢查返回值發(fā)送失敗就把這條消息寫入一個待重試隊列并觸發(fā)連接清理。亂序問題則多半出在重連邏輯上客戶端斷線重連后緊接著用新連接發(fā)送消息但服務(wù)端還沒把舊連接的資源清理完兩條連接同時發(fā)消息順序就亂了。解決方式是在客戶端加一個簡單的序號每條消息帶一個遞增的 seq服務(wù)端按 seq 排序后廣播。這個小改動對聊天室體驗提升非常明顯尤其是移動端網(wǎng)絡(luò)切換場景下。6.3 內(nèi)存暴漲與 fd 泄漏內(nèi)存暴漲的排除路徑我有一個經(jīng)驗順序先看連接表大小對不對再看有沒有緩存數(shù)組只增不減最后看是不是日志寫太多。fd 泄漏的典型癥狀是系統(tǒng)報too many open files進(jìn)程明明沒多少連接但耗著幾千個句柄。原因往往是 TCP 連接已經(jīng)斷開服務(wù)端沒有及時觸發(fā) Close 事件連接表里殘留了大量已死的 fd。這種問題要兩手抓服務(wù)端除了依賴 Close 事件還要做周期性的心跳超時掃描每隔一段時間遍歷連接表把超過 N 秒未活躍的連接主動 close。這個掃描機(jī)制是長連接服務(wù)的最后一道保險必須有。6.4 排錯速查表癥狀可能原因快速定位方法解決方案握手失敗返回 200Nginx 沒傳 Upgrade 頭看響應(yīng)頭是否含101 Switching Protocols檢查 Nginx 的proxy_set_header配置連接 60 秒左右斷開代理層空閑超時看客戶端心跳幀是否持續(xù)發(fā)送配置proxy_read_timeout或客戶端加心跳消息能發(fā)但收不到廣播連接表未正確記錄或清理服務(wù)端打印當(dāng)前連接數(shù)檢查登錄回調(diào)是否寫入fdToUserClose 是否清理內(nèi)存持續(xù)上漲全局?jǐn)?shù)組只增不減輸出內(nèi)存占用和連接數(shù)對比所有緩存數(shù)組綁定清理路徑做心跳超時掃描重啟后大量客戶端卡死客戶端重連風(fēng)暴看服務(wù)端啟動瞬間的連接日志客戶端用指數(shù)退避重連封頂 30 秒多人同時說話消息錯亂本機(jī)時間戳不可靠打印收到消息的先后順序客戶端加 seq 序號服務(wù)端按序廣播6.5 一個實用工具在線調(diào)試 WebSocket 接口最后分享一個很實用的調(diào)試技巧。做 WebSocket 開發(fā)時瀏覽器控制臺的調(diào)試驗證效率其實不高我一直推薦先用現(xiàn)成的在線 WebSocket 調(diào)試工具做接口驗證連上地址、手動發(fā)送 JSON 幀、查看返回幀。這樣可以快速區(qū)分問題是服務(wù)端還是前端。我曾經(jīng)排查一個“前端收不到消息”的 bug先用調(diào)試工具連接服務(wù)端手動發(fā)登錄和聊天消息結(jié)果服務(wù)端立刻返回了正確廣播問題一下子就鎖定了在前端省了大量時間。我個人在實際調(diào)整這個項目時最深的體會是WebSocket 服務(wù)端的核心不是“代碼跑通”而是“穩(wěn)定地長期跑”。一開始代碼能通很簡單但真正決定它能不能上線的是心跳策略、內(nèi)存管理、斷線重連、代理配置這一堆周邊細(xì)節(jié)。另外這個項目的源碼結(jié)構(gòu)適合繼續(xù)擴(kuò)展比如把 JSON 協(xié)議換成帶二進(jìn)制協(xié)議、增加房間分組、接一個基于 Redis 的在線狀態(tài)服務(wù)改動的思路都是現(xiàn)成的。如果你正準(zhǔn)備上手從這套邏輯開始比直接抄完整項目代碼要有用得多。