在大型促销（如双11、Black Friday）或突发事件发生时，营销团队常常需要瞬间向百万甚至亿级用户推送通知。如果直接在请求处理程序中同步循环发送，会导致请求线程阻塞、内存与 CPU 飙升，最终压垮服务器。
在 On-call 场景里也有类似需求，比如 Status Page 服务发布故障信息，就是一个巨大的邮件广播。比如很多人关注并订阅了 DeepSeek 的 Status Page，如果 DeepSeek 故障，Flashduty 就要给所有订阅用户发送邮件通知。
高并发通知系统的核心设计原则是：将"通知生成"与"通知分发"彻底解耦，从追求"发送速度"转变为保障"系统安全"。
核心架构设计
1. 基于队列的异步处理
系统引入消息队列（如 Kafka、RabbitMQ）作为缓冲区。
- 流程：API 接收到推送请求后，仅负责将通知任务写入队列，随后立即返回。
- 优势：队列能有效吸收瞬间的流量峰值。即使 100 万条通知在几秒内涌入，后端 Worker 也可以按照自身能够承受的受控速率逐步消费并处理，保护了应用层。
2. 独立扩展的 Worker 集群
将处理通知的 Worker Fleet（工作节点集群）与前端应用服务器分离，实现独立弹性扩缩容。
- 系统可根据队列堆积深度（Queue Depth）动态调整 Worker 数量。例如队列中有 1 万条消息时运行 10 个 Worker，达到 100 万条时自动扩容至 1000 个 Worker，而应用层始终不受影响。
关键技术决策与陷阱应对
陷阱一：下游第三方服务限流（Rate Limiting）
当我们拥有足够的 Worker 时，瓶颈往往会转移到下游通知渠道（如 Firebase、APNs、邮件服务商）。如果盲目追求高并发，会导致下游触发频率限制。
- 决策 ：在 Worker 层引入速率限制器（Rate Limiter）。即使队列中有海量数据，Worker 也必须严格按照下游供应商允许的最大速率发送。此时队列积压是安全的，比压垮依赖项要好得多。
陷阱二：分布式环境下的重复发送（幂等性设计）
在分布式系统中，"至少交付一次（At-least-once）"是常见网络策略。如果 Worker 成功发送了通知，但在向队列提交 Confirm/Offset 之前崩溃，队列会重新投递该消息，导致用户收到重复通知。
- 决策 ：确保通知处理具备幂等性（Idempotency）。
- 为每条通知生成全局唯一的
notification_id。 - 在调用下游发送前，向数据库（或 Redis）尝试插入该 ID：
sql
INSERT INTO processed_notifications (notification_id) VALUES ('NOTIF-1001');- 利用数据库的唯一约束（Unique Constraint），若插入成功则执行发送；若失败（报主键冲突）则说明已处理过，直接跳过。
陷阱三：亿级（100M+）超大流量过载
当面对 1 亿以上用户时，如果一次性把 1 亿条消息全部打入 Kafka，会导致消息队列瞬间过载或 OOM。
- 决策 ：分阶段逐步生成。将"活动定义"与"通知生成"分离开。由一个专用的生成器（Generator）以可控的步长逐步（Progressively）创建通知任务并分批打入队列，避免一次性淹没队列。
优化与运维保障
1. 批量分发（Batching）
- 对比：如果 1 次 API 调用仅发送 1 条通知，100 万条通知就需要 100 万次网络 I/O。
- 优化：大部分主流供应商提供 Batch API。通过将 500 条通知合并为一个 Batch 请求发送，100 万条通知只需 2000 次请求，极大降低了网络开销与上下文切换带来的损耗。
2. 失败重试与死信队列（DLQ）
由于设备 Token 失效、邮箱错误或临时网络抖动，通知必然会出现失败。
- 策略：引入带有指数退避（Exponential Backoff）的重试队列。
- 死信队列：限制最大重试次数（如 5 次）。超过上限仍失败的消息投递到死信队列（Dead Letter Queue），由运维团队后续通过监控进行排查与异步修复。
3. 异步事件驱动的数据分析（Delivery Tracking）
市场部通常需要追踪"已发送、已送达、已打开、失败"等指标。
- 设计 ：通知供应商的回调（Callbacks）通过异步事件进行处理。分析系统的流量与通知发送的流量相互独立，避免数据分析压力反噬发送链路。
总结
一个生产级别的海量通知系统，核心在于控制力：
- 用队列控制对内部应用层的冲击。
- 用限流控制对外部下游的冲击。
- 用幂等解决分布式架构的副作用。
- 用批处理与异步事件榨干系统性能。