内存队列应优先用带缓冲的channel分片处理，而非直接连Kafka；Redis PubSub仅适合广播，精准推送需用其存状态或离线消息；RabbitMQ/Kafka应置于持久化层，配合批量确认与Producer复用；sync.Pool复用Message可降低GC压力。
用 channel 做内存队列，别一上来就连 Kafka
消息队列在高并发推送系统里不是“必须上中间件”，而是分层用：内存队列扛瞬时峰值，持久化队列保最终一致。直接把 amqp.Publish 或 redis.Publish 塞进每条推送逻辑，等于把网络延迟和外部依赖拖进热路径，QPS 上不去还容易雪崩。
实际做法是：每个 shard（按用户 ID 或标签哈希分片）配一个带缓冲的 chan *Message，容量设为预估峰值的 1.5 倍（比如每秒 2000 条 → 缓冲 3000）。写入时用 select + default 非阻塞发送，失败立刻走降级（如打日志+进离线池），不卡住业务 goroutine。
- 缓冲太小：频繁丢任务，
select总走default分支 - 缓冲太大：内存占用高，GC 压力大，且掩盖了下游消费慢的真实问题
- 零缓冲 channel：生产者极易被阻塞，尤其在心跳协程或 HTTP handler 里用，会拖垮整个连接
Redis PubSub 适合广播，不适合精准推送
如果你的场景是「向所有在线 iOS 用户推运营公告」，redis.PubSub 没问题；但如果是「给 user_id=12345 推订单状态变更」，它就完全不合适——PubSub 是无状态的，无法做连接筛选、ACK 回执、重试控制，也查不到谁在线、谁掉线了。
真正该用 Redis 的地方是：做跨节点连接状态同步（比如用 SETNX user:12345:conn_id conn123 EX 60 维护最后活跃连接）、或者存离线消息的轻量兜底（LPUSH user:12345:offline_msgs msg_json），而不是当主推送通道。
立即学习“go语言免费学习笔记（深入）”；
- PubSub 的
Subscribe是阻塞调用，一个 goroutine 只能盯一个 channel，横向扩展难 - 消息不持久，服务重启就丢，没 ACK 机制，发了等于没发
- 订阅关系增删要发
UNSUBSCRIBE/SUBSCRIBE，高频变更时 Redis 连接数暴涨
RabbitMQ / Kafka 要用在“落库后”那层，不是“连接写入”那层
推送链路本质是三段式：接入层（WebSocket 连接）→ 内存分发层（shard + channel）→ 持久化层（MQ + DB）。RabbitMQ 和 Kafka 应该出现在第三段，只承载两类消息：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 需要离线触达的（用户不在线时暂存，上线再拉）
- 需强一致审计的（如支付结果通知，必须落 MQ 才算“已发出”）
这时候要注意：不要让每个 amqp.Publish 都等 confirm，会严重拖慢吞吐。正确姿势是批量 confirm + 异步错误回调，例如用 channel.Confirm 开启确认模式，再起一个 goroutine 监听 channel.NotifyPublish 处理失败消息，失败后进重试队列（内存版即可，用 time.AfterFunc 实现）。
另外，Kafka 的 Producer 实例要复用，别每次发都 new 一个——它的内部有缓冲池和后台 flush goroutine，new 太多会触发大量 TCP 连接和 goroutine 泄漏。
sync.Pool 复用 Message 结构体，避免 GC 成瓶颈
每秒几万条推送，如果每次都 &Message{...}，GC 会频繁触发 STW，延迟毛刺明显。用 sync.Pool 管理可复用对象是成本最低的优化之一。
关键点在于：Pool 里的对象不能带“跨生命周期”的引用（比如闭包、未清理的 bytes.Buffer 底层数组），否则可能引发数据污染。典型写法：
var msgPool = sync.Pool{
New: func() interface{} {
return &Message{
Payload: make([]byte, 0, 512),
Headers: make(map[string]string),
}
},
}
func getMsg() *Message {
m := msgPool.Get().(*Message)
m.Payload = m.Payload[:0] // 清空 slice
for k := range m.Headers {
delete(m.Headers, k)
}
return m
}
func putMsg(m *Message) {
msgPool.Put(m)
}
别忘了每次用完立刻 putMsg(m)，否则 Pool 就失效了；也别在 Pool 对象里存 context 或 channel，它们生命周期不可控。
真正容易被忽略的是：内存队列的消费 goroutine 必须和连接 goroutine 分开，且消费端要加 recover，否则一条 panic 会 kill 整个 shard 的消息处理流——这比 MQ 不可用更致命，因为它是静默中断，连告警都难触发。
