Golang构建即时通讯后端：Websocket百万连接架构解析

Go的net/http默认无法支撑10万WebSocket连接，因其每连接一goroutine模型导致内存与文件描述符耗尽，且缺乏限流、心跳、异常驱逐机制。

为什么 net/http 默认无法撑住 10 万 WebSocket 连接

Go 的 http.Server 默认用每个连接一个 goroutine 模型，看似轻量，但百万级连接下，goroutine 调度、内存开销（每个约 2KB 栈）、TCP 连接状态维护（net.Conn + bufio.Reader/Writer）会迅速吃光内存和文件描述符。更关键的是，http.Serve() 内部没有连接限流、心跳复位、异常连接自动驱逐机制，长连接堆积后，新连接 accept 失败、超时、或被内核丢包。

实操建议：

• 必须替换默认 http.Server 的 ConnState 回调，主动跟踪 StateNew/StateClosed，做连接数硬限（比如 atomic.AddInt64(&connCount, 1) > 100000 就直接 conn.Close()）
• 禁用 http.Server.ReadTimeout 和 WriteTimeout —— 它们对长连接有害；改用应用层心跳（如每 30s conn.WriteMessage(websocket.PingMessage, nil)）+ SetReadDeadline() 动态刷新
• 避免在 http.HandlerFunc 里直接升级 WebSocket：upgrader.Upgrade() 后立即 spawn goroutine 处理读写，否则 handler 返回前连接可能已被客户端断开，导致 panic: write tcp: use of closed network connection

gorilla/websocket 升级时最常踩的三个坑

它不是“开箱即用”的高性能方案，很多默认配置直面百万连接就露馅。

常见错误现象：客户端反复重连、服务端日志刷屏 websocket: close sent、CPU 突升但吞吐不涨。

实操建议：

• 设置 Upgrader.CheckOrigin = func(r *http.Request) bool { return true } 前务必加域名白名单校验，否则 DDoS 攻击可伪造 Origin 耗尽连接数
• 必须调 upgrader.Subprotocols 显式声明支持的子协议（如 []string{"v1"}），否则某些 CDN 或代理会静默拦截 Upgrade 请求
• upgrader.WriteBufferSize 和 ReadBufferSize 别设成 0 —— 默认 4096 太小，高并发消息 burst 时频繁 malloc，建议设为 65536；但也不要盲目设大，超过 OS socket buffer（net.core.wmem_max）会触发阻塞

连接管理不能只靠 map[string]*websocket.Conn

用 map 存连接看着简单，实际在分布式部署、滚动更新、连接异常中断时完全不可靠：key 冲突、goroutine 泄漏、map 并发写 panic、节点宕机后用户状态丢失。

使用场景：需要支持单点登录踢人、消息离线缓存、跨实例广播（如群聊）。

实操建议：

• 连接元数据（用户 ID、设备 ID、登录时间、IP）必须单独存到带 TTL 的 Redis Hash，键为 conn:{connID}；连接对象本身只保留在内存中，生命周期与 TCP 连接严格一致
• 用 sync.Map 存活跃连接映射（userID → connID），但仅作本地快速查找；所有“踢指定用户”操作，先删 Redis，再查 sync.Map 找到对应 connID，最后安全关闭连接（conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseGoingAway, ""))）
• 不要依赖 defer conn.Close() 清理 —— 必须在 readPump 和 writePump 两个 goroutine 都退出后，显式从 sync.Map 删除并通知 Redis 过期

横向扩展时，WebSocket 连接无法“真正共享”

WebSocket 是有状态的长连接，TCP 层绑定在某个实例上，负载均衡器（如 Nginx、ALB）只能做连接分发，无法把同一个用户的后续请求“导回”原节点 —— 所以广播、私信、状态同步都得走外部通道。

性能影响：如果所有消息都经 Redis Pub/Sub 中转，延迟增加 2–5ms，QPS 上限受限于 Redis 单节点吞吐（通常 5–10w ops/s）。

实操建议：

• Nginx 必须开启 proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade";，否则 WebSocket 握手失败，错误信息是 HTTP/1.1 400 Bad Request
• 用 Redis Streams 替代 Pub/Sub 做消息总线 —— 支持消费者组、ACK、重放，避免消息丢失；每个服务实例起一个消费者组成员，独立 ACK
• 对低延迟要求高的操作（如打字状态、在线状态），用 Redis Bitmap 或 Sorted Set 做轻量聚合，避免每条状态都走消息队列

真正的难点不在代码怎么写，而在于你得时刻清楚：哪部分状态在内存、哪部分在 Redis、哪部分其实根本没存 —— 连接断了，用户重连时，该从哪恢复上下文，这个逻辑一旦漏掉一环，前端就会卡在“正在连接…”。