system-design-notes通知如何做到不丢不重3层可靠性设计避坑清单【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes在 system-design-notes 的“设计一个通知系统”章节中作者给出了一个每天处理数千万条推送、短信、邮件的可靠通知系统设计方案。核心就 3 层队列缓冲 数据落库 去重重试层层兜底让通知做到不丢失、不重复。通知系统为什么会“丢”或“重”通知系统由触发服务、通知服务器、消息队列、Worker 和第三方通道APNs、FCM、短信、邮件组成初版设计中所有业务逻辑挤在一台通知服务器上存在两大隐患单点故障服务器一挂整条链路瘫痪正在处理的通知直接丢失耦合严重发送失败时没有缓冲触发方只能反复重试容易把重复请求打穿。第 1 层消息队列解耦削峰缓冲改进后的架构把数据库、缓存移出通知服务器横向扩展多台服务器并在每个渠道iOS Push、Android Push、SMS、Email前各挂一条消息队列这一层解决“丢”通知事件先写入队列再慢慢消费服务器瞬时故障时消息积压在队列里而不是丢失队列在高并发时充当缓冲器把尖峰流量摊平Worker 按自己的节奏取任务发送。第 2 层数据落库 重试失败可恢复光有队列还不够。如果 Worker 拉到消息后发送失败消息就消失了。章节给出的做法是Notification log 数据库每条通知持久化落库Worker 失败时可重新捞取处理重试机制第三方服务调用失败时自动重试直到送达。这一层解决“失败可恢复”任何一次发送失败都能凭数据库里的记录再试一次而不依赖请求方重新触发。第 3 层事件 ID 去重 状态机跟踪消灭重复重试机制有个副作用——可能把同一条通知发两遍。章节的对策按事件 ID 去重通知事件到达时先查 event ID见过就丢弃没见过才发送状态机跟踪记录每条通知的完整生命周期便于定位问题配套组件还包括通知模板、用户级 opt-in/opt-out 设置表、针对用户维度的限流、监控队列长度以动态扩缩 Worker、以及打开率/点击率等事件追踪指标API 侧用 AppKey AppSecret 做鉴权。避坑清单照抄这 4 点#坑对策出处1发送失败就丢消息消息队列解耦 缓冲Readme.md2Worker 挂掉任务蒸发通知日志数据库持久化 重试机制Readme.md3重试导致重复推送事件 ID 去重检查Readme.md4失败原因无从查起状态机全链路跟踪pending/sent/deliver/errorReadme.md一句话总结消息队列管“缓冲”数据库管“兜底”事件 ID 管“去重”——3 层各司其职百万级通知系统才能真正做到不丢不重。【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考