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