使用 Golang 框架处理大规模 WebSocket 连接-Golang-PHP中文网

gorilla/websocket默认一连接一goroutine模式在5000+连接时卡顿，根本原因是同步阻塞调用引发goroutine泛滥、系统调用频繁、锁竞争激烈及无错误隔离；百万级需改用非阻塞I/O、缓冲区复用与事件驱动模型。

使用 golang 框架处理大规模 websocket 连接

靠 gorilla/websocket 默认一连接一 goroutine 模式，撑不住 10 万连接；百万级必须放弃阻塞读写、复用缓冲区、绕过内存驻留状态。

为什么 gorilla/websocket 在 5000+ 连接时就开始卡顿

不是代码写得慢，是模型本身有三处硬伤：

conn.ReadMessage() 和 conn.WriteMessage() 都是同步阻塞调用，每个连接强绑定一个 goroutine，5000 连接 = 5000 个常驻 goroutine，调度器压力陡增
每次 WriteMessage() 触发一次系统调用 + 一次内存拷贝 + 一次 TCP 缓冲区写入，连接数上万后，CPU 时间全耗在 syscall.write 和锁竞争上
for-range 广播时，一个弱网连接卡住，整轮发送就停住，其余连接全被拖累；且无错误隔离，write 失败（如 use of closed network connection）常导致后续连接被跳过

如何避免 goroutine 泄漏和 map 并发 panic

连接异常关闭时，reader/writer goroutine 若没正确退出，会永远卡在 ReadMessage() 或 select 上，状态为 [IO wait] 却无法回收；而所有对 clients map[*Client]bool 的操作（增、删、遍历）并发读写会直接触发 fatal error: concurrent map iteration and map write。

reader goroutine 必须监听 io.EOF、websocket.CloseAbnormalClosure、net.OpError 三类典型断连信号，收到后主动 close(c.send) 并发注销消息
所有 clients map 操作必须收束到单个 hub.run() goroutine 中串行处理：注册/注销走 register/unregister channel，广播走 broadcast chan []byte
绝对不要用 sync.RWMutex 包裹 map——它挡不住底层哈希表扩容时迭代器失效，仍会 panic

心跳保活必须双向驱动且超时严格对齐中间设备

gorilla/websocket 的 Ping/Pong 不自动启用，不手动设 handler + 定时发帧，Nginx、ALB 或防火墙空闲超时后连接会被静默断开。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

服务端必须启动独立 goroutine，每 pingPeriod（建议设为 pongWait * 0.9）调用 conn.WriteControl(websocket.PingMessage, nil, time.Now().Add(writeWait))
SetPongHandler 必须做两件事：调用 conn.SetReadDeadline(time.Now().Add(pongWait)) 重置读超时，并更新应用层心跳时间戳（如 c.HeartbeatTime = time.Now()）
pongWait 必须小于路径上所有中间设备空闲超时，例如 Nginx 默认 proxy_read_timeout 60s，则 pongWait 应 ≤ 55 * time.Second；writeWait 单独设为 10 * time.Second，防止 WriteMessage 卡死

百万连接必须换库 + 调系统参数 + 改 I/O 模型

默认模式下，100 万连接会吃掉至少 3GB 内存（仅读写缓冲区），并生成百万 goroutine，光调度开销就压垮 CPU。

操作系统层面必须调：ulimit -n 1048576（或 Go 启动时用 syscall.Setrlimit 主动申请）、sysctl -w net.netfilter.nf_conntrack_max=2621440（防 conntrack 表溢出丢包）、sysctl -w net.ipv4.ip_local_port_range="1024 65535"
Go 层面必须换库：gobwas/ws 支持缓冲区复用，实测 100 万连接内存从 3.2GB 降至 860MB，goroutine 数量稳定在几百个；它的 ws.ReadFrame(conn, buf) 显式传入 buf，可从 sync.Pool 获取并归还
不能依赖 conn.ReadMessage() 阻塞等待，要把 socket 设为非阻塞，用 epoll/kqueue 统一轮询所有连接，只在数据就绪后派发到 worker goroutine 解析，worker 数量可控（如 32 个）