WebSocket实战：从轮询到真正的服务端推送，技术细节与工程落地-代码聚汇网

WebSocket实战：从轮询到真正的服务端推送，技术细节与工程落地

WebSocket服务端推送实时通信

|难度：普通|阅读约 49 分钟

1. 从"轮询地狱"到真正的服务端推送

1.1 一个让我下决心换方案的真实场景

我印象很深的一次经历，是给一个内部工单系统做"待办提醒"功能。需求很简单：当后台有人分配了新工单给当前用户时，页面上要立即弹出一条提醒，不用用户按 F5 刷新。

第一次做的时候，我图省事用了前端定时轮询，每 3 秒发一个 AJAX 请求去问后端"有没有新消息"。开发环境只有我一个测试用户，一切正常。结果一上生产，一百多个在线用户同时挂着页面，每 3 秒一次轮询，再加上每个人可能开了两三个标签页，峰值 QPS 直接多了上百。数据库连接池被打到告警，内网带宽也明显异常。后端日志里全是"Query OK but no rows affected"这种毫无意义的查询，运维大哥直接在群里发了一句"谁写的轮询，赶紧改"。

那时候我才意识到，轮询这种方案的本质是"让客户端不断去问服务器有没有消息"，而大多数时间里，答案是"没有"。这就像一个人每隔几秒就去信箱前看一眼，大部分时候信箱是空的，耗时间不说，信箱管理员也被你来回走动的脚步声烦得不行。真正需要的是：信箱里一旦塞进一封信，管理员主动喊你一声——这就是服务端推送。

WebSocket 就是在这样的场景下被我正式引入项目的。它的核心价值并不是"比 HTTP 快"，而是改变了通信模型：原先 HTTP 是"一来一回"的短期连接，服务器永远不能主动开口；WebSocket 建立一条长连接后，两边随时都能发消息。这个模型上的差别，才是实时应用的根基。

1.2 HTTP、SSE 与 WebSocket 的取舍

在确定用 WebSocket 之前，我还认真对比过另外两个方案：HTTP 长连接（也叫长轮询）和 SSE（Server-Sent Events，服务器发送事件），包括很多人容易搞混的 HTTP/2 推送。这里我用自己的话帮你理一遍。

长轮询（Long Polling）：客户端发请求，服务器不立刻返回，而是把请求挂着，等有新数据了再响应；客户端收到响应后立即发起下一次请求。听上去像是推送，但每次请求都得重新走一遍 HTTP 握手、请求头、响应头，连接也无法做到真正意义上的"复用"。一旦消息频率高、用户量大，请求次数依然很吓人，因为每个消息都要建立一次完整的 HTTP 事务。
SSE：建立在 HTTP 之上的单向推送通道，服务器可以持续往客户端吐数据。它最大的优势是原生支持：浏览器里直接用 EventSource API，不需要额外协议，断线重连、消息 ID 追踪这些机制浏览器都帮你做好了。缺点是单向的，客户端只能通过普通 HTTP 请求给服务器发数据，且它依赖 HTTP 连接，对于需要大量双向交互的场景会显得别扭。
WebSocket：一次握手，双向通道，数据帧头开销小（服务端到客户端只有 2~10 字节的帧头），而且支持二进制数据。劣势也很明显：需要服务端额外实现协议支持，部署时反向代理要特殊配置，连接管理要自己操心心跳、超时、清理。

所以说实话，如果你的需求只是"服务器给客户端单向推送消息，比如行情刷新、日志流"，用 SSE 就够了，完全不必上 WebSocket。如果需求是"聊天室、协同编辑、实时白板、游戏对战"这种双向实时交互，WebSocket 才是顺手的选择。我当时选择 WebSocket，就是因为工单系统里那个"提醒"只是第一步，后面还要做多人在线编辑工单批注，双向通信跑不掉，一步到位更省事。

这里也提醒一句：别被"实时"两个字冲昏头脑。WebSocket 不是银弹，它是"长连接 + 全双工"的代名词，随之而来的是连接状态管理、扩容复杂度、代理层兼容性等问题。如果是刚起步的小项目，老老实实用 SSE 或短轮询，反而更稳。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. WebSocket 协议关键的四个细节

2.1 握手为什么必须走 HTTP Upgrade

很多人第一次看 WebSocket 抓包的时候会有点懵：明明自己连的是 ws:// 地址，为什么第一条请求长这样：

http复制GET /ws/chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Version: 13

这就是 WebSocket 的握手请求，本质上是 HTTP 协议里定义的一种 "Upgrade" 升级机制。WebSocket 在设计之初就选择不另起炉灶，而是基于 HTTP/1.1 的 101 Switching Protocols 状态码完成协议切换。这样做的直接好处是：它可以用现有的 HTTP 基础设施和端口（80/443）对外提供服务，能穿透大部分防火墙和代理，甚至能复用已有的鉴权中间件——你在 HTTP 层做的 Cookie、Token 校验，在握手阶段就能生效。

握手过程我简单拆一下：

客户端发一个带 Upgrade: websocket 头的 GET 请求；
服务器校验请求头，生成响应头 Sec-WebSocket-Accept，返回 101 Switching Protocols；
双方确认升级成功，TCP 连接保持打开，后续帧不再走 HTTP 语义，而是走 WebSocket 帧。

其中 Sec-WebSocket-Key 是一段随机 Base64 字符串，服务器会把它拼上固定 GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11，做一次 SHA-1 哈希再 Base64 编码，得到 Sec-WebSocket-Accept 的值。这个设计的目的不是加密，而是让服务器确认"你是真的理解 WebSocket 协议"，防止某些代理服务器无意中把普通 HTTP 请求误升级。

提示：在 Python 的 websockets 库或 FastAPI 中，这一整套握手逻辑框架已经封装好了，你不需要手动算 SHA-1。但理解这一步很重要，否则你在排查"Nginx 返回 400 Bad Request"这类问题时会一头雾水。

2.2 数据帧、掩码与分片传输

从 TCP 层面看，WebSocket 通信是一串连续的"帧"，一帧包含 FIN、Opcode、Mask、Payload Length、Masking Key、Payload Data 这些字段，结构比你想象中精简得多。服务端到客户端的数据帧，头部通常只有 2~10 个字节；而 HTTP 请求光一个请求头就动不动几百字节。这也是为什么在高频小消息场景下，WebSocket 能显著节省带宽。

帧结构里有个容易被人忽略的点：客户端发往服务器的帧必须做掩码处理（Masking），而服务器发往客户端的帧不需要掩码。

为什么？初期很多人觉得这是多余的，但协议设计者这么做的真实考量是：防止缓存投毒攻击。早期网络环境中，有些代理服务器会把在不同 TCP 连接上传送的数据误当成同一段数据来做缓存，如果恶意页面能操控 WebSocket 帧里的字节，就能构造出类似 HTTP 请求的内容去污染代理缓存，造成跨站安全风险。掩码就是让帧载荷变得"不可预测"，即使被代理误读，也没法推导出真正要传送的内容。

再说分片。WebSocket 允许把一条消息拆成多个帧传输：第一个帧的 FIN 为 0，Opcode 表示消息类型（如文本是 1、二进制是 2），中间帧 Opcode 为 0（continuation），最后一个帧 FIN 为 1。这种设计的好处有两个：一是发送方可以边生成数据边发送，不必等整条消息拼完；二是大数据块可以切分，避免占据 TCP 发送缓冲区过久。

不过在日常 Python 开发中，大家用的库已经自动完成了分片和重组，你不需要手动处理。知道它的存在是为了排查一个比较隐蔽的坑：某些 WebSocket 客户端库在处理大消息时，如果对端过早断开，会导致"stream disconnected before completion"这类异常，本质上就是分片消息没收到最后一个 FIN 帧。我在生产环境遇到过，后面还会细说。

2.3 Ping/Pong/Close：控制帧的工程意义

WebSocket 定义了三种控制帧：Close（Opcode 8）、Ping（Opcode 9）、Pong（Opcode 10）。

控制帧最容易被初学者忽略，但工程上它们举足轻重。Ping/Pong 就是协议层面的"你还在吗"探测机制。一端发送 Ping 帧，对端必须回复 Pong 帧，否则就可以认为连接已死亡。很多代理服务器（包括 Nginx）有连接空闲超时机制，如果不定期发 Ping 维持活跃，空闲连接会被中间设备静默切断。但 TCP 本身有 keepalive 机制，为什么 WebSocket 还要自己做心跳？因为 TCP keepalive 默认超时是 2 小时，周期太长，而且它在某些 NAT 网关和设备上会被忽略，无法确保应用层的存活。

Close 帧用于双方协商关闭连接，可以携带一个状态码（如 1000 表示正常关闭、1001 表示服务下线）和一段关闭原因文本。注意：收到 Close 帧后，对端应该回一个 Close 帧作为确认，然后才真正关闭 TCP 连接，这是协议规范，但很多库和实现为了省事会直接断开。

我在用 FastAPI 开发时，websockets 库底层会自动处理 Ping/Pong，但如果我自己写原生 socket 服务，就不得不手动实现。稳妥的做法是：心跳周期设置得比代理层的超时时间短，一般建议 20~30 秒发一次 Ping，代理超时设 60 秒。

2.4 子协议与扩展协商

WebSocket 还有一个概念叫 Subprotocol（子协议）。它允许在握手阶段协商"应用层协议"，比如 graphql-ws、mqtt、json-rpc 等。做法是客户端在握手请求里带 Sec-WebSocket-Protocol: mqtt，服务器选择支持的某个协议后，在响应中返回相同的值。

这个机制对 Python 开发者来说最大的价值是：如果你做一个 WebSocket 服务，需要同时服务 Web 前端和内部自动化客户端，一种做法是给前端子协议传 "web"，给内部客户端传 "agent"，握手后第一帧就按各自协议解析，省去自己设计"消息类型字段"的麻烦。

另外，协议里还有个 permessage-deflate 扩展用于压缩数据。它对文本消息有不错的压缩率，但由于压缩会有 CPU 开销和内存开销，在消息体积不大（几十个字节）的情况下反而可能得不偿失。我实测过，如果消息都是 JSON 且存在大量重复键名，打开压缩后带宽能下降 40% 以上，但单个消息延迟会增加 0.5~2ms。这个度要拿捏，不能无脑开。

3. Python 侧实现：从连接管理到消息广播

3.1 方案选型：FastAPI 还是原生 websockets 库

Python 里做 WebSocket，主流选择基本是这几个：

方案	特点	适用场景
`websockets` 库	纯 asyncio 实现，协议实现完整，API 简洁	轻量级服务、自研服务器、无 Web 框架绑定的场景
FastAPI / Starlette	内置 WebSocket 支持，依赖 `uvicorn` 提供 ASGI 服务	想同时提供 REST API 和 WebSocket，统一鉴权模型
Django Channels	基于 ASGI，支持 channel layer、group 管理	重度使用 Django 生态，ORM 模型不能丢的项目
`aiohttp`	自带 WebSocket 支持和路由	习惯 aiohttp 全家桶，或已有基于 aiohttp 的服务

我个人的建议是：如果你还没引入 Web 框架，只是写个临时工具，直接用 websockets 库就够了，依赖轻，学习曲线低。如果你想做一个长期维护的 Web 应用，大概率最终还是会用 FastAPI，因为登录鉴权、API 路由、请求参数校验这些配套能力早晚需要，没必要为了 WebSocket 单独再起一个服务。

FastAPI 底层靠的是 Starlette 的 ASGI 接口，支持 WebSocket 对象；uvicorn 线程池和事件循环配合，理论上单进程可以支撑数千个并发连接。当然，"能撑住"和"撑得稳"是两码事，后面会展开。

3.2 一个可直接运行的实时通知中心

下面给你一个可以直接跑的 FastAPI WebSocket 示例，实现一个简单的"全局通知广播"服务。把它存成 main.py，用 uvicorn main:app --reload 启动。

python复制from fastapi import FastAPI, WebSocket, WebSocketDisconnect
from typing import List

app = FastAPI()

class ConnectionManager:
    def __init__(self):
        # 保存所有活跃连接
        self.active_connections: List[WebSocket] = []

    async def connect(self, websocket: WebSocket):
        # 接受握手请求
        await websocket.accept()
        self.active_connections.append(websocket)

    def disconnect(self, websocket: WebSocket):
        # 连接关闭时移出列表
        if websocket in self.active_connections:
            self.active_connections.remove(websocket)

    async def broadcast(self, message: str):
        # 广播给所有人
        for connection in self.active_connections:
            try:
                await connection.send_text(message)
            except Exception:
                # 发送失败说明连接可能已断开，交给调用方决定是否清理
                pass

manager = ConnectionManager()

@app.websocket("/ws/notify")
async def websocket_endpoint(websocket: WebSocket):
    await manager.connect(websocket)
    try:
        while True:
            # 阻塞等待客户端消息；不发消息的连接就一直挂在这
            data = await websocket.receive_text()
            # 收到任何消息，就广播给所有人
            await manager.broadcast(f"公告: {data}")
    except WebSocketDisconnect:
        # 客户端主动断开
        manager.disconnect(websocket)
        await manager.broadcast("有人掉线了")
    except Exception as e:
        # 其他异常：要么是心跳超时，要么是协议错误
        manager.disconnect(websocket)
        print(f"连接异常: {e}")

这个代码的逻辑很直白：每个连接进入后，先加入 ConnectionManager 的列表；然后在 while 循环里等待客户端消息。收到消息后不是只回给发送者，而是广播给所有连接。

如果你只是想做个"服务端主动推送"的接口，比如后台系统往通知中心发一条数据，那么可以加一个 REST 接口来触发广播：

python复制from pydantic import BaseModel

class NotifyRequest(BaseModel):
    content: str

@app.post("/api/notify")
async def api_notify(req: NotifyRequest):
    await manager.broadcast(req.content)
    return {"ok": True, "sent": len(manager.active_connections)}

这样代码就有完整闭环了：任意系统调用 /api/notify 接口，所有在线 WebSocket 客户端立刻收到消息。这个模式我在工单系统里的初始版本就是这么用的。

注意：上面 catch Exception 之后只做打印，没有强制移除连接。实际项目里，如果你发现某条连接 send_text 一直失败，应该直接调用 disconnect 清理，否则它会一直留在 active_connections 里，导致广播时循环越来越慢。后面讲内存泄漏时会细聊。

3.3 连接管理器：注册、广播与清理

ConnectionManager 看似简单，但它是 WebSocket 服务里最核心的组件，几乎决定了服务的稳定性和扩展性。我在做过几个项目后，最深的体会是：管理连接这件事，远比收发消息复杂。

先说并发问题。单进程 asyncio 模型里，active_connections 是列表，broadcast 是异步遍历发送，在同一个事件循环里执行，不存在多线程的同时写问题。但如果你在 Flask 这类多线程框架里手动实现 WebSocket，或者用多个 worker 进程，就要考虑锁了。FastAPI 配合 uvicorn 单进程跑，暂时不用纠结锁，但一旦开多个 worker，连接列表就是各进程独立的，跨进程广播就成了大问题——这也是第 5 节要讲分布式方案的原因。

再聊广播时的异常处理。每个连接的网络状况都不一样。一个客户端可能前一秒还在，下一秒 WiFi 断了他自己不知道，TCP 断开要等一段时间才能被发现。如果你在 broadcast 里不做异常处理，某个连接一断，整个广播循环就中断，后排用户全部收不到消息，这是非常隐蔽且致命的 bug。

改进后的管理类我会这么写：

python复制import asyncio

class ConnectionManager:
    def __init__(self):
        self.active_connections = {}
        self.counter = 0

    async def connect(self, websocket: WebSocket):
        await websocket.accept()
        self.counter += 1
        connection_id = self.counter
        self.active_connections[connection_id] = websocket
        return connection_id

    async def disconnect(self, connection_id: int):
        ws = self.active_connections.pop(connection_id, None)
        if ws is not None:
            try:
                await ws.close(code=1000)
            except Exception:
                pass

    async def broadcast(self, message: str):
        dead_ids = []
        for cid, ws in list(self.active_connections.items()):
            try:
                await ws.send_text(message)
            except Exception:
                dead_ids.append(cid)

        for cid in dead_ids:
            await self.disconnect(cid)

这里的改动有两个亮点：一是用字典存连接，分配唯一 ID，方便精确删除；二是广播失败时先把异常连接收集起来，等循环结束再统一清理，避免在遍历列表过程中直接修改它。虽然是"小改动"，但生产环境上一个线程崩一棵树的惨痛教训，不是瞎编的。

另外，连接数一定要有上限保护。如果做的是面向公网的服务，我建议在 connect 里加判断：

python复制MAX_CONNECTIONS = 5000

async def connect(self, websocket: WebSocket):
    if len(self.active_connections) >= MAX_CONNECTIONS:
        await websocket.close(code=1013)  # Try Again Later
        return None
    await websocket.accept()
    ...

1013 是 WebSocket 协议预留给"服务端过载"的状态码，客户端收到后会知道服务端暂时进不去，而不是报协议错误。这个保护可能是整个服务里最不起眼但最有用的代码之一。

4. 部署与运维：线上踩过的三个坑

4.1 Nginx 反代 WebSocket 的配置与踩坑

WebSocket 开发环境跑通之后，第一步就是上 Nginx 反代。如果你照抄普通 HTTP 代理配置，大概率会得到一个 502 Bad Gateway 或者 400 Bad Request，原因就是 Nginx 默认不转发 Upgrade 和 Connection 请求头。

正确的配置关键点如下：

nginx复制map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {
    listen 80;
    server_name your-domain.com;

    location /ws/ {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }
}

几个细节解释一下：

map 指令把请求头里的 Upgrade 值映射到 Connection 头。没有 Upgrade 头时（普通 HTTP 请求），Connection 头设为 close，避免影响其他请求。
必须显式设置 proxy_http_version 1.1，因为 HTTP/1.0 不支持 Upgrade。
proxy_read_timeout 和 proxy_send_timeout 默认是 60 秒，如果没有业务层心跳，连接会在 60 秒后超时断开。这也是很多人遇到"WebSocket 连上 1 分钟就断"的最常见原因。你要么把这两个值调大（比如 300s），要么应用层做 Ping/Pong 心跳，让中间层认为连接还活着。

踩坑记录里最诡异的一次是：Nginx 配置改好之后，前端连 ws://domain/ws/notify 依然报 403。排查了半天，发现是 allow/deny 规则里给 IP 段匹配写错了一个掩码，导致 Nginx 在握手阶段直接拒绝了。所以遇到 WebSocket 连接失败，先看 Nginx error log，不要只看后端日志。

4.2 心跳保活真的不只是协议要求

很多新手误以为设置了 proxy_read_timeout 为 60 秒、同时把心跳周期设为 50 秒就万事大吉了。但真实生产环境的链路是：

客户端 -> 浏览器 -> 公司网络/运营商 NAT -> 云负载均衡 -> Nginx -> Python 服务端

这条链路上，每一层都可能因为"空闲"而切断连接。NAT 网关尤其讨厌，它会维护一张"内网 IP+端口 <-> 外网 IP+端口"的映射表，如果一段时间没有数据包经过，映射条目会被回收。此时 TCP 连接并没有发 FIN 包，你的服务端还傻乎乎地以为客户端在线。

所以心跳的真正作用，不是"满足协议"，而是定期产生数据包，维持整条链路的活跃状态，防止中间设备回收连接。理论上心跳间隔必须小于链路上最短的空闲回收时间。在没有确切数据的情况下，我一般按以下规则设置：

心跳周期：30 秒
服务端 Ping 客户端：30 秒一次
客户端收到 Ping 后，自动回复 Pong（大部分 WebSocket 客户端库自动完成）
服务端如果 90 秒内没有收到任何数据帧或 Pong 帧，就判定连接过期，主动 close

FastAPI 里如何做服务端主动心跳？你可以在每个连接配一个后台任务，或者用一个全局定时器扫描所有连接。最省事的做法是在连接处理函数开始时就安排一个心跳协程：

python复制import asyncio

async def heartbeat(websocket: WebSocket):
    while True:
        await asyncio.sleep(30)
        try:
            await websocket.send_text("__ping__")
        except Exception:
            break

@app.websocket("/ws/notify")
async def websocket_endpoint(websocket: WebSocket):
    # 注意：同一个连接上 send 和 receive 并发进行
    hb_task = asyncio.create_task(heartbeat(websocket))
    try:
        while True:
            data = await websocket.receive_text()
            ...
    except WebSocketDisconnect:
        ...
    finally:
        hb_task.cancel()

要注意的是，ASGI 应用中同一个 WebSocket 连接上的并发读和并发写是允许的吗？ 在主流 ASGI 服务器（uvicorn、hypercorn）里，response 通道提供异步写的能力，所以并发写是可行的。但你需要小心使用锁，避免多条协程同时 send_text，否则可能出现帧交错，导致客户端解析出错。可以用一个 asyncio.Lock 保护发送操作：

python复制class Connection:
    def __init__(self, websocket: WebSocket):
        self.websocket = websocket
        self.send_lock = asyncio.Lock()

    async def send(self, message: str):
        async with self.send_lock:
            await self.websocket.send_text(message)

这属于"不碰上不觉得是问题，碰上才知道厉害"的细节。群里有个同事就碰到过：两个广播协程同时往同一个连接发数据，客户端频繁报 NoneType: None 的解析错误，愣是查了两天。

4.3 内存泄漏排查：连接对象怎么悄悄堆积

WebSocket 服务跑久了，内存曲线一直往上涨，这是运维阶段最常见的头疼问题。罪魁祸首通常是连接没有正确清理。

我之前排查过一个案例：active_connections 列表长度和 ss -s 看到的 TCP ESTABLISHED 状态连接数对不上，列表里多出很多"幽灵"连接。仔细分析后发现，客户端断网后并没有发 Close 帧，TCP 连接处于半开状态，服务端的 receive_text 一直阻塞在那里，既不抛异常也无结果，所以 while 循环永远不会退出，disconnect 也就永远不被调用。那些连接就像僵尸一样，永远留在列表里。

解决思路有两种：

服务端主动探测：结合前面说的心跳机制，定期检查最后活跃时间，超时就主动关闭连接、移出列表。
借助框架的超时机制：用 asyncio.wait_for 包裹 receive_text，比如 120 秒没等到任何数据就主动断开：

python复制while True:
    try:
        data = await asyncio.wait_for(websocket.receive_text(), timeout=120)
        # 处理消息
    except asyncio.TimeoutError:
        # 长时间没消息，主动断开
        await websocket.close(code=1001)
        break

注意：这个做法要和前端逻辑配合。如果前端偶尔超过 120 秒不说话，你的服务就把它踢了，体验很差。所以生产环境里我倾向于"心跳 + 标签"方案：每收到一个数据帧就更新 last_active_time，心跳协程检查所有连接，超过 90 秒没活跃的就 close。把判断逻辑从"有没有数据"改为"有多久没数据"，更合理。

5. 从单机到分布式：如何扛住海量连接

5.1 单机的瓶颈在哪里

用一个 uvicorn 单进程跑 WebSocket 服务，能扛多少连接？这个答案受限于两个资源：文件描述符（fd） 和内存。

每个 TCP 连接消耗一个 fd，Linux 默认单进程 fd 上限通常是 1024，需要手动调大：

bash复制ulimit -n 65535

内存方面，每个 WebSocket 连接在 Python 进程里至少占 20~50KB（连接对象、缓冲区、协程栈），一万个连接就是 200~500MB。注意这是一个基础开销，还没算业务数据、队列缓冲、TLS 握手状态。所以单机撑三万到五万连接是可以做到的，但也到极限了。

另一个隐性问题：单进程模型下，Python 的 GIL 虽然不阻塞 await 期间的 IO，但广播消息时的 JSON 序列化、字符串处理这些 CPU 操作仍然会被 GIL 限制。如果每个客户端收到的消息内容相同、序列化结果不同，一万个连接就是一万次重复运算，CPU 很快就达到瓶颈。

那么问题来了：当你需要撑更多用户，或者需要横向扩容时，WebSocket 连接怎么在多个服务实例之间协同？

5.2 Redis Pub/Sub 实现跨节点消息广播

WebSocket 连接是粘滞在某个进程上的。一个客户端先连到了节点 A，后续消息就只能从节点 A 通过这个 TCP 连接发给它。如果要广播给所有客户端，就必须让所有节点都知道"有一条消息要广播"，然后把消息发给自己节点上对应的连接。

最简单的跨节点通信方式是 Redis Pub/Sub。原理是：每个服务节点启动时订阅一个全局频道；某个节点收到 REST API 推送后，把消息发布到 Redis 频道；所有节点（包括自己）从订阅里收到这条消息，再广播给自己进程内维护的 WebSocket 连接。

用 redis-py 的 asyncio 接口写出来大概是这样的：

python复制import asyncio
import json
import redis.asyncio as aioredis
from fastapi import FastAPI, WebSocket

app = FastAPI()

class RedisBroadcast:
    def __init__(self, redis_url: str, manager: ConnectionManager):
        self.redis = aioredis.from_url(redis_url)
        self.manager = manager
        self.pubsub = None

    async def subscribe(self):
        self.pubsub = self.redis.pubsub()
        await self.pubsub.subscribe("chat:global")
        asyncio.create_task(self._listen())

    async def _listen(self):
        async for message in self.pubsub.listen():
            if message["type"] == "message":
                data = json.loads(message["data"])
                # 本地节点广播
                await self.manager.broadcast(data["content"])

    async def publish(self, content: str):
        await self.redis.publish("chat:global", json.dumps({"content": content}))

流程很清晰：无论是哪个节点收到 /api/notify，都往 Redis 发一条消息；每个节点都订阅了同一个频道，收到后广播本机连接。这样每个节点只需对自己进程内的 WebSocket 连接负责，全部节点合起来就是"一个逻辑上的实时服务"。

需要注意的点：

Redis Pub/Sub 是"即发即弃"的，消息不会持久化。如果某个节点在消息发布时短暂下线，它就永远错过这条消息。对实时通知来说通常可以接受，但对"消息不丢"有要求的场景，需要换成 Stream 或引入消息队列。
订阅连接需要做重连处理。Redis 服务器重启、网络抖动都会导致 pubsub 连接断开，你的 listen() 循环会异常退出。建议捕获异常后 sleep 几秒重连，保证服务自愈。

5.3 更多扩展思路：消息队列、网关与连接粘滞

如果业务复杂度更高，比如要做"给特定用户推送""消息持久化""离线消息补发"，单纯 Redis Pub/Sub 就不够了。这时候需要考虑引入消息队列，比如 RabbitMQ、Kafka 或 Redis Stream。

给特定用户推送，本质上是"按用户维度路由"。我建议的方案是：服务端维护一个 user_id -> connection_id 的映射，每个节点有一个本地映射表；发布消息时带上目标 user_id，通过 Redis Pub/Sub 发送到所有节点，各节点检查自己本地有没有这个用户、再决定是否推送。这种做法会有广播放大效应（一条消息发给所有节点），但在节点数量不多的内部系统里完全够用。

对于节点变多的情况，更高效的路由方式是用网关层做"连接粘滞"：比如在 Nginx 层用 IP Hash 或者根据 user_id 取模，把同一用户的所有 WebSocket 连接固定路由到同一个后端节点。这样发布消息时就只需要转发到那个特定的节点。但这种方式要求网关和后端的一致性配置，而且一旦节点扩容缩容，Hash 结果会变化，连接需要重新迁移，复杂度并不低。

还有一个思路是引入现成的实时网关中间件，比如 EMQX、NATS、轻量级自研网关。我目前的经验是：在节点少于 10 个的场景下，Redis Pub/Sub 的简单粗暴完全够用；节点更多时，优先考虑独立的实时消息中间件，而不是在业务进程里硬扛。

另外，服务启动时的冷启动问题也要注意。如果服务有多个副本，某个副本新启动后，它还没有任何连接，但也订阅了 Redis 频道——这个没关系，只是暂时没有可推送的连接对象。但如果你用 --workers 4 启动 FastAPI，uvicorn 默认会开 4 个进程，每个进程都会订阅同一批 Redis 频道，广播消息会重复推送吗？不会，因为每个进程只管自己的连接，不会跨进程重复发送，所以是安全的。这一点我特意确认过，就放心多了。

最后再分享一个实践小技巧：写一个 /healthz 接口，返回当前进程的活跃连接数、内存占用、最近心跳时间。很多线上问题不是靠代码 review 发现的，而是靠监控曲线先警觉的。 我在部署 WebSocket 服务时，一定会把连接数接入监控，设定阈值告警。连接数突然掉到接近零，通常说明服务被重启或者网络出问题；连接数持续上涨，可能是内存泄漏；连接数波动剧烈，可能是客户端的重连逻辑写得太激进。

WebSocket 这个领域，入门容易，做好难。从协议握手的细节到生产环境的代理配置，从单机连接管理到分布式广播，每一步都有值得琢磨的地方。至少对我而言，那次被轮询逼到墙角之后换到 WebSocket，不只是换了个技术栈，更是换了一套思考实时应用的模型。希望这篇实战心得，能让你在你的项目里少走几个弯路。