go高性能消息推送关键在三处精准控制：连接层保活限流防泄漏，分发层按channel分片+批量投递避遍历，存储层幂等ack+异步落库防阻塞；4c8g可撑30w+活跃pv。
用 Go 语言写高性能实时消息推送后台，关键不在堆机器或加协程，而在于三处精准控制：连接不泄漏、分发不遍历、存储不阻塞。
连接层：保活与限流是底线
每个 WebSocket 连接必须配独立的读循环（readLoop）和写循环（writeLoop），避免 conn.Write() 阻塞导致心跳失效。真实压测中，90% 的连接异常源于心跳超时设置不当。
- 心跳间隔设为 30 秒，服务端用 time.AfterFunc 主动发 Ping，客户端 pong 后重置定时器
- 超时未响应（如 90 秒）直接 close 连接，不等 GC 回收
- 连接元数据（userID、deviceID）存 sync.Map，禁止在热路径查 Redis 或 DB
- 连接对象用 sync.Pool 复用，每次取用后显式清空字段，防止脏数据残留
分发层：按 channel 分片 + 批量投递
把所有在线用户塞进一个 map[userID]*Conn 然后 for-range 推送，是典型性能反模式。360 万用户里 10% 在线，单次广播就要遍历数万连接，CPU 直接打满。
- 按业务维度（如 tenant_id、topic、tag）做连接分片，每个分片用 RWMutex 保护，锁内只做指针操作
- 消息进入分发队列后，批量聚合相同目标的消息，一次 writev 或批量 send
- 广播类消息走 pub/sub 模型，私聊类走 userID 映射，避免全量扫描
存储与可靠性：幂等 + 异步 + 分级兜底
“已发送”不等于“已送达”。线上最常出问题的是没做 ACK 去重，或重试逻辑卡主线程。
- 每条消息带唯一 messageID（推荐 uuid.NewV7()），客户端收到后主动上报 {messageID, userID}
- 服务端用 redis.SetNX("ack:"+messageID, "1", time.Hour) 实现幂等去重
- 未 ack 消息 30 秒后触发首次重试（指数退避，最多 2 次），任务丢进内存 timer.AfterFunc
- 最终失败消息写入 Kafka retry_topic，由独立消费者异步重推
- 离线消息用 zset 存未读 ID，score 设为过期时间戳，定时 ZRANGEBYSCORE 清理
选型建议：轻量可控优先于功能堆砌
Socket.IO 等封装库自带心跳、断连重试、房间抽象，但多一层协议就多一分延迟和不确定性。对高频交易、IoT 指令、协同编辑等场景，更推荐基于 gorilla/websocket 或 ls1xt/murmur 这类纯协议库自建——你掌控握手流程、消息格式、状态同步策略，也更容易定位瓶颈。
- 需要快速验证模型？用 WuKongIM 做嵌入式内核，专注业务逻辑
- 需横向扩展？gopush-cluster 的 Web+Comet+Message 三层拆分清晰，适合中大型部署
- 追求极致资源效率？Chatwire 或 goim 的 Comet 层设计，专为十万级长连接优化
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
