单台服务器无法支撑千万级websocket连接，因系统资源（如文件描述符、内存、tcp参数）远低于需求，必须分层解耦、状态外置（redis cluster）、广播异步化（kafka+扇出），接入层仅负责协议升级与tls终结，业务逻辑完全分离。
单台服务器撑不住千万级 WebSocket 连接，必须分层解耦、状态外置、广播异步化——这是所有成功案例的共同起点。
为什么单机扛不住 100 万连接？
不是 CPU 先崩，是系统资源先告急：
-
ulimit -n默认通常为 1024 或 65535，远低于百万连接所需；不调高会直接报EMFILE错误 - 每个连接在 Go 中至少占用 2KB 栈 + 缓冲区（默认 4KB~64KB），100 万连接轻松吃掉 1–3GB 内存，且 GC 压力陡增
- Linux 默认
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog过低，导致握手阶段丢包、SYN queue overflow - Node.js 的
ws库单进程无法突破 10 万连接瓶颈，即使多进程也难统一广播；uWebSockets可达百万，但需关闭 TLS 或用硬件卸载否则 CPU 瓶颈明显
连接层必须与逻辑层分离
大厂落地时最常踩的坑，就是把用户认证、消息路由、业务处理全塞进一个 WebSocket 进程里。结果是：扩连接就得扩业务，故障互相拖垮。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 接入层只做协议升级、TLS 终结、IP 限流、连接 ID 分配（如用
hash(ip:port) % N分片），不做任何业务判断 - 连接元数据（
conn_id、user_id、room_id、last_ping）必须写入 Redis Cluster，而非本地 map —— 否则横向扩容后广播找不到人 - 心跳由接入层统一收发（ping/pong 帧），业务层只监听
redis pub/sub或 Kafka 主题，避免每个连接起 goroutine 定时器 - 断连清理不能靠
onClose回调：网络闪断时回调不触发，得靠 Redis key 过期 + 单独的 sweep worker 扫描
广播不能“遍历连接”，必须扇出（fan-out）
对 50 万在线用户群发一条弹幕，如果用 for 循环调 conn.WriteMessage()，延迟会从毫秒飙到秒级，且极易阻塞 event loop。
- 正确路径：业务服务 → Kafka Topic（如
room:1001） → 多个接入节点消费 → 本地查 Redis 获取该房间当前连接列表 → 批量写入（非逐个） - 写入时用
conn.SetWriteDeadline()防卡死，失败连接立即标记为 stale 并踢出 Redis - 高频小消息（如位置更新）启用 WebSocket 帧压缩（
permessage-deflate），但注意 Nginx 默认不透传压缩头，需显式配置proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade"; - 超大房间（如百万观众直播间）进一步分组：按连接 ID 哈希分 100 个子频道，每个子频道只推给 1 万连接，再由前端聚合渲染
真实压测中暴露最多的三个盲点
文档不提、教程不说，但上线后必现：
- Nginx 作为反向代理时，默认
proxy_read_timeout 60s，WebSocket 空闲连接会被静默断开——必须设为0或足够大，并配proxy_socket_keepalive on - 客户端浏览器有并发连接数限制（Chrome 对同一域名最多 6 个 TCP 连接），长连接多时需用多个子域名（
ws0.example.com～ws9.example.com）做连接打散 - 云厂商 SLB（如阿里云 ALB、AWS NLB）对 WebSocket 支持不一：ALB 支持完整生命周期，但 NLB 不感知 HTTP Upgrade，需改用 TCP 模式并自行处理健康检查
