Go WebSocket 广播为什么会被慢客户端拖住：发送队列、丢弃策略和分片 Hub

行情房间刚过晚高峰，服务端 CPU 还没顶满，用户却开始反馈“同一条更新有人先看到、有人晚几秒才看到”。看连接数时才发现，房间里混着一批网络很差的移动端；广播循环按客户端逐个写入，一条写得慢的连接把后面所有人都排在了后面。Go 的 WebSocket 广播在这里卡住，通常不是 goroutine 数不够，而是慢客户端被放进了所有人共用的发送路径。

要解决慢客户端拖垮全房间广播的问题，核心是把公共广播路径和每个客户端的网络写入路径彻底拆开，用带明确丢弃策略的有界队列承接消息转发，再通过分片把热点房间的影响范围限制住。

一个慢连接把整个房间拖成了串行等待

最容易写出来的广播逻辑是遍历房间成员，然后直接向每条 WebSocket 连接发送消息。连接少、网络稳定时，这段代码看起来没有问题；一旦其中某个客户端读得慢，网络写入就可能停在那条连接上。后续客户端并不是“各自慢一点”，而是在等待同一条广播循环往前走。

现场通常会同时出现三个信号：消息发送 P99 拉长、某些房间的待发消息越来越多、断线重连数在弱网时段抬高。这里先别急着把队列容量调大。容量变大只会让堆积晚一点显现，不能改变一条慢连接正在占用公共广播路径的事实。

旧 Hub 为什么在连接增长后撑不住

单 Hub 管理一个房间或一组房间并不天然有问题，问题在于它同时承担了成员管理、广播遍历和网络写入。成员变化很频繁时，广播还要同步等待网络，Hub 的职责就开始互相干扰：注册、退出和消息分发都在抢同一条处理路径。

github.com/coder/websocket 的文档提醒了两个容易被忽略的边界：连接需要持续读取，控制帧才能被处理；它的 Writer 同时只允许一个写入器。即使所用库允许某些方法并发调用，业务层也更适合让每个客户端只有一个明确的写循环，这样关闭、超时和指标归属才不会散在各处。

把网络写入从 Hub 中拆出去

改造的第一步很克制：Hub 不再直接等待网络，而是尝试把消息交给客户端的有界队列。真正向连接写数据的动作由客户端自己的写循环处理。这样广播循环只处理内存里的入队结果；一条网络慢连接最多拖住自己的队列，不会让整个房间停在一次写入上。

type Client struct {
    id  string
    out chan []byte // 有界队列，容量由消息语义决定
}

func (c *Client) offer(msg []byte) bool {
    select {
    case c.out 

这段代码刻意没有在 default 分支里做网络写入或无限重试。offer 返回 false 只是说明该客户端的队列已满，接下来怎么处理取决于消息是否允许丢失。Hub 可以记录一次队列满事件，也可以交给房间策略处理；但不应该在广播循环里等待这条慢连接追上。

func (c *Client) writeLoop(ctx context.Context, conn *websocket.Conn) {
    ctx = conn.CloseRead(ctx)
    for {
        select {
        case msg, ok := 

示例使用 github.com/coder/websocket 的 CloseRead 和 Write。它表达的重点不是固定两秒这个数值，而是把写入超时、连接终止和单写循环放在同一个客户端边界里。实际超时需要结合心跳间隔、消息体大小和移动网络情况压测后再定。

队列满时，先分清消息能不能丢

“队列满就丢”不是通用方案。行情快照、鼠标位置、在线人数这类状态型消息，旧消息往往可以被新消息覆盖；聊天、订单状态、支付结果这类事件型消息如果被悄悄丢弃，业务语义就错了。架构调整前需要先写清楚每一类消息的补偿方式。

• 状态型消息：队列满时可合并为最新状态，客户端下一帧看到最新值即可。
• 事件型消息：队列满时更适合主动断开并让客户端按游标补拉，或转入可确认的持久消息通道。
• 控制类消息：关闭、鉴权失效和服务维护通知应保留单独优先级，不能和高频状态更新混在同一队列里。

我更愿意把“丢弃”理解成一种业务协议，而不是一个性能开关。只有客户端能从快照或游标恢复时，覆盖旧状态才是安全的；否则你看到的只是延迟下降，漏消息的代价会在之后以另一种形式回来。

房间热点再上来时，用分片 Hub 隔离影响面

每个客户端有独立队列后，热门房间仍可能让成员遍历和入队本身变重。这时可以按 roomID 的稳定哈希把房间分到多个 Hub：同一房间始终由同一个 Hub 管理，不同房间进入不同分片。这样一次热点房间的注册、退出和广播，不会挤占所有房间的处理时间。

分片数不是越多越好。分得太细会增加跨分片管理、监控聚合和重平衡复杂度；分得太少则看不到隔离效果。比较稳妥的做法是先让分片数固定、可配置，观察每个分片的连接数、广播频率和队列满次数，确认热点是否集中后再调整。迁移时还要保证同一房间在切换期间不会被两个 Hub 同时管理，否则成员集合和消息顺序都会变得难以解释。

改完以后，监控要能看到“慢在哪里”

这类改造上线后，不要只看总连接数。真正有判断价值的是每个房间或分片的发送 P99、客户端队列深度、队列满次数、主动断开次数、写入超时次数，以及重连后补拉的成功率。它们放在一起，才能区分“消息太多”“单条消息太大”“少数弱网连接拖慢”还是“某个 Hub 成了热点”。

1. 先在压测环境构造正常连接与受限网络连接混合的房间，确认慢连接不再拉高其他连接的发送耗时。
2. 检查状态型消息在队列满时是否能收敛到最新状态，事件型消息是否走了明确的补偿路径。
3. 灰度后按分片查看 P99、队列深度和断开原因；只要队列满次数快速上涨，就回到消息语义和连接质量排查。
4. 保留回退开关，让房间可以先退回单分片处理，避免在热点时段同时改变分片数和消息策略。

相关问题

每个客户端都起一个写循环，goroutine 会不会太多？

连接型服务本来就需要维护每条连接的生命周期。关键不在于是否有一个写循环，而在于它是否会被无界队列、无超时写入和无法退出的阻塞拖住。先观察 goroutine 数、退出耗时和内存曲线，再决定是否要进一步调整架构。

所有消息都能放进同一个发送队列吗？

不建议。状态更新和可靠事件的补偿方式不同，维护通知的优先级也不同。至少要在消息模型上区分是否允许覆盖、是否需要确认，以及重连后的恢复来源。

分片 Hub 能保证跨房间消息顺序吗？

不能自动保证。分片通常只保证同一房间由稳定分片处理。跨房间顺序如果是业务约束，需要由上层事件序号、持久化日志或协调机制定义，不能把它寄托在广播遍历顺序上。

只加大 channel 缓冲能解决卡顿吗？

它只能推迟队列满的时刻。慢客户端持续读不动时，增大缓冲会换来更多内存占用和更晚的反馈。先给队列上限，再决定满时的业务动作，才是可控制的方案。

把慢连接当成局部故障，而不是全房间故障

广播系统最怕的是把每条连接的网络问题升级成公共路径的等待。Hub 负责管理成员和分发机会，客户端写循环负责网络边界，有界队列负责显式暴露背压，房间分片负责限制热点影响面。把这几个职责拆开以后，慢连接仍然需要处理，但它不再有机会拖住整个房间。

参考：github.com/coder/websocket 官方 Go Packages 文档。