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