Golang扇出模式优化通知推送效率

Golang中的扇出（fan-out）模式能显著提升Push通知的发送效率，其核心优势在于通过并发而非串行处理大幅提高吞吐量；但盲目滥用goroutine（例如一次性启动百万级协程）反而会拖垮系统——导致HTTP连接池耗尽、复用机制失效，甚至触发下游服务限流或断连；真正高效的扇出实践关键在于“可控并发+资源复用”，推荐使用带缓冲的channel（如容量100）精准限流，让每个goroutine在获取信号后才执行推送，兼顾性能与稳定性。

为什么 fan-out 比串行发 push 快，但用错 goroutine 反而更慢

因为并发不是越多越好。起 100 万个 goroutine 去调推送 SDK，大概率触发连接池耗尽、HTTP 客户端复用失效、甚至被目标服务限流或断连。真正有效的扇出，是控制并发数 + 复用底层资源。

实操建议：

• 用带缓冲的 channel 控制最大并发数（比如 make(chan struct{}, 100)），每个 goroutine 发送前先 ，发完再 sem
• 所有 goroutine 共享同一个 *http.Client，别在循环里 new；尤其要设置 Transport.MaxIdleConns 和 MaxIdleConnsPerHost（建议 ≥ 并发数）
• 避免在 goroutine 内部做阻塞日志、同步写文件等操作——这些会拖慢整个扇出队列

context.WithTimeout 必须套在每个推送请求上，不能只套外层

单个推送请求卡住（比如第三方服务响应超慢），会把对应 goroutine 挂死，导致该 goroutine 占着并发槽位不释放。外层 timeout 只能杀掉启动逻辑，拦不住已跑起来的 goroutine。

常见错误现象：goroutine 数持续上涨、内存缓慢增长、部分用户收不到通知但无报错

实操建议：

• 每个推送调用都包一层 ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second)，用完立刻 cancel()
• 如果推送 SDK 不支持 context.Context（如老版本 apns2），得自己加 select + time.After 做超时兜底
• 注意：不要复用同一个 ctx 给多个请求——子 ctx 的 cancel 会影响其他请求

用户分片和错误重试必须解耦，别让失败用户堵住整批扇出

直接把千万用户切块后扔进 goroutine，某一块里有个 token 失效或网络抖动，整个 chunk 就算失败，重试时又得重走扇出流程，浪费资源还拖慢整体。

使用场景：iOS token 过期、Android FCM 设备离线、华为 HMS 接口返回 8000 错误

实操建议：

• 扇出只负责“发起请求”，成功/失败都通过 chan Result 归集，主流程不做阻塞等待
• 失败项（含 HTTP 5xx、token 无效、设备不可达）单独收集，走异步重试队列（比如用 redis zset 延迟重试）
• 分片大小建议 100–500 人/片，太小增加调度开销，太大失败影响面大

别忽略推送结果的幂等解析，APNs 和 FCM 的错误结构完全不同

APNs 返回 410 表示 token 失效，FCM 返回 "error": "NotRegistered" 才是等价含义；华为 HMS 则用 8000 码表示设备离线。混用判断逻辑会导致大量脏数据残留。

性能影响：错误码解析不精准 → 无效重试增多 → 推送通道被限频 → 后续正常请求也被拒

实操建议：

• 为每种推送通道写独立的 parseError(resp) 函数，返回标准化的 PushResult{Status: "invalid_token", RawErr: ...}
• 对 APNs，检查响应 header apns-id 和 body 中 reason 字段；对 FCM，必须读 response body JSON，不能只看 HTTP status
• 记录原始响应体（至少采样 0.1%），否则线上遇到新错误码根本没法定位

最麻烦的其实是错误归因——同一份日志里可能混着网络超时、证书过期、token 格式错误、设备厂商策略变更。没做通道级错误分类，查问题就是碰运气。

好了，本文到此结束，带大家了解了《Golang扇出模式优化通知推送效率》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！