说起来，

在大型促销或突发事件发生时营销团队常常需要瞬间向百万甚至亿级使用者推送通知。说起来，如果直接在请求处理程序中同步循环发送。会导致请求线程阻塞、内存与 CPU 飙升，最终压垮服务器。

在 On‑call 场景里也有类似需求。比如 Status Page 服务发布故障信息，就是一个巨大的邮件广播。比如很多人关注并订阅了 DeepSeek 的 Status Page。如果 DeepSeek 故障，Flashduty 就要给所有订阅使用者发送邮件通知。

高并发通知程序的主要设计原则是：将“通知生成”与“通知分发”彻底解耦，从追求“发送速度”转变为保障“程序安全”。

主要架构设计

. 基于队列的异步处理

程序引入消息队列作为缓冲区。

• 流程API 接收到推送请求后仅负责将通知任务写入队列，随后立即返回。
• 优势队列能有效吸收瞬间的流量峰值。不过，即使万条通知在几秒内涌入。后端 Worker 也可以按照自身能够承受的受控速率逐步消费并处理，保护了应用层。

. 独立 的 Worker 集群

将处理通知的 Worker Fleet 与前端应用服务器分离，实现独立弹性扩缩容。

• 程序可根据队列堆积深度 Worker 数量。怎么说呢，例如队列中有万条消息时运行个 Worker。达到万条时自动扩容至个 Worker，而应用层始终不受影响。

关键技术决策与陷阱应对

说到陷阱一，下游第三方服务限流

当我们拥有足够的 Worker 时瓶颈往往会转移到下游通知渠道。如果盲目追求高并发，会导致下游触发频率限制。

• 决策在 Worker 层引入速率限制器。即使队列中有海量数据，Worker 也必须严格按照下游供应商允许的最大速率发送。此时队列积压是安全的，比压垮依赖项要好得多。

再看陷阱二。分布式环境下的重复发送

在分布式程序中，“至少交付一次”是常见网络策略。如果 Worker 成功发送了通知，但在向队列提交 Confirm/Offset 之前崩溃。队列会重新投递该消息，导致使用者收到重复通知。

• 决策确保通知处理具备幂等性.
1. notification_id.

INSERT INTO processed_notifications VALUES;老实说，

1. 唯一约束。若插入成功则执行发送，若失败则说明已处理过直接跳过。

说到陷阱三。亿级超大流量过载

当面对亿以上使用者时如果一次性把亿条消息全部打入 Kafka，会导致消息队列瞬间过载或 OOM。

• 决策:分阶段逐步生成 . 将“活动定义”与“通知生成”分离开。由一个专用的生成器 以可控步长逐步 创建通知任务并分批打入队列，避免一次性淹没队列。

调整与运维保障

. 批量分发

• 对比 : 如果 次 API 调用仅发送 条通知,万条通知就需要 万次网络 I/O.
• 调整 : 大部分主流供应商提供 Batch API。通过将 条通知合并为一个 Batch 请求发送,万条只需 次请求,极大降低网络开销与上下文切换带来的损耗.

. 失败重试与死信队列

由于设备 Token 失效、邮箱错误或临时网络抖动,通知可能会出现失败.

• 策略 : 引入带有指数退避 的重试队列.
• 死信队列 : 限制最大重试次数. 超过上限仍失败的信息投递到死信 Queue,由运维团队后续通过监控进行排查与异步修复.

. 异步事件驱动的数据分析

行业市场部通常需要追踪 “已发送、已送达、已打开、失败”等指标.

• 设计 : 通知供应商回调通过异步事件处理一下. 分析程序流量与通告发送流量相互独立。避免数据分析压力反噬发送链路.

一个生产级别海量通告程序主要在于控制力 .

1. <强>用 队 列 控 制 内 部 应 用 层 的 冲击 . /强>
2. <强>用 限 流 控 制 对 外 下 游 的 冲击 . /强>
3. <强>用 幂 等 解 决 分 布 式 架 构 的 副 效 . /强>
4. <强>用 批 务 与 异 步 电 案 榨 干 性 能 . /强>