Go 语言如何高效处理百万级的 WebSocket 连接-Golang-PHP中文网

靠默认“一连接一goroutine+gorilla/websocket”模式无法支撑百万连接，因内存爆满、goroutine调度失衡、文件描述符耗尽；可行路径是系统调优+异步i/o+库级缓冲复用。

go 语言如何高效处理百万级的 websocket 连接

直接说结论：靠默认的“一连接一 goroutine + gorilla/websocket”模式，根本撑不住百万连接——内存爆掉、goroutine 调度失衡、系统文件描述符耗尽，三者必中其一。真正可行的路径是：系统调优打底 + 异步 I/O 替代阻塞读写 + 库级缓冲复用。

为什么 `gorilla/websocket` 在百万连接下内存暴涨

它为每个连接分配独立的读写缓冲区（默认各 4KB），100 万连接就是 ~8GB 内存；更关键的是，它的 ReadMessage/WriteMessage 是同步阻塞调用，必须配一个 goroutine 等着数据就绪，导致百万 goroutine 常驻，调度开销远超业务逻辑本身。

实操建议：

别在 for 循环里直接 go handleConn(conn) 启动 goroutine 处理每个连接
避免调用 conn.SetReadDeadline 配合 ReadMessage，这会强制维持 goroutine 生命周期
如果必须用 gorilla/websocket，至少把 WriteBufferPool 设为共享池，但读缓冲仍无法复用

用 `gobwas/ws` 替换库能省多少内存

gobwas/ws 的核心优势是「连接间缓冲区复用」：它不为每个连接 malloc 新 buffer，而是从全局池里借，用完归还。实测 100 万连接下，内存占用从 gorilla 的 3.2GB 降到 860MB 左右，且 goroutine 数量稳定在几百个而非百万级。

关键代码差异：

// gorilla：缓冲区绑定到 conn 实例
conn, _ := upgrader.Upgrade(w, r, nil)
conn.SetReadBufferSize(4096) // 每个 conn 独占一份
<p>// gobwas：显式传入 buffer，可复用
buf := getBuf() // 从 sync.Pool 获取
conn, <em>, </em>, err := ws.UpgradeHTTP(r, w)
_, err = ws.ReadFrame(conn, buf) // buf 用完后 put 回 pool
</p>

注意：gobwas/ws 不兼容 gorilla 的 API，需重写消息收发逻辑，但换来的是确定性的内存上限。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

Linux 系统参数不调，Go 代码再优也起不来

百万连接意味着至少 100 万个 socket 文件描述符，而 Linux 默认 ulimit -n 是 1024。没调这个，accept 直接返回 EMFILE 错误，新连接全被拒。

必须调整的几项：

ulimit -n 1048576（临时）或在 /etc/security/limits.conf 中设 * soft nofile 1048576
sysctl -w net.netfilter.nf_conntrack_max=2621440（防止 conntrack 表溢出丢包）
sysctl -w net.ipv4.ip_local_port_range="1024 65535"（扩大可用端口范围）

Go 服务启动前，务必用 syscall.Getrlimit(syscall.RLIMIT_NOFILE, &rLimit) 主动检查当前限制，不达标就 panic，别等连接堆到 99 万才失败。