这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
消息通知
从简单的邮件提醒到千万级推送系统
一步步设计完整的消息通知架构
系统设计消息通知推送
系统演进路线
从定时脚本到多端通知平台
第 1 版
定时脚本推送
创业 App 先用 PHP 脚本每分钟扫库，把待发送通知推给用户。
通知表crontab第三方推送
能发出去，但延迟、重复和慢查询会随着用户增长一起爆发。
第 2 版
通知服务化
推送延迟和重复投诉出现，通知需要从业务代码中拆出来。
事件接入消息队列推送服务站内信
通知从脚本变成异步链路，发送、存储和重试开始分层。
第 3 版
用户体验治理
用户半夜被打扰、热门内容刷屏，需要偏好和限流。
偏好设置免打扰聚合通知频控
通知系统不只追求送达，还要尊重用户选择和打扰成本。
生产版
多端通知平台
用户有手机、平板、Web，多渠道、多设备状态必须统一。
多端同步未读计数渠道路由失败重试效果监控
生产通知平台要同时保证触达、状态一致和可运营。
课程简介
系统总览
通知系统总览
围绕多渠道投递、用户偏好、限频、重试和数据回执设计通知平台。
入口
业务事件
模板参数
用户偏好
投递
站内信
短信邮件
App 推送
治理
限频退订
失败重试
送达统计
消息通知系统连接业务事件和用户触达。它不是简单调用推送接口，而是要在正确时间、通过正确渠道、以用户能接受的频率，把重要消息送到用户手里。只要用户规模上来，通知系统就会同时面对延迟、重复、失败、免打扰、多端同步、站内信存储和防骚扰问题。
这门课从一个创业 App 的通知事故开始，逐步把数据库轮询脚本演进为覆盖推送、站内信、偏好管理、限流和完整架构的通知平台。
学习路线
- 一切从一个周末开始：从推送延迟、重复通知和用户投诉理解问题背景。
- 通知基础：重新拆解通知的触发、投递、状态、渠道和可靠性要求。
- 推送渠道：比较 iOS APNs、安卓厂商推送和第三方推送服务的差异。
- 站内信：设计持久化消息中心，支持已读未读和历史查询。
- 多端同步：处理一个用户多台设备之间的未读数和状态一致性。
- 限流防骚扰：通过聚合、频控、优先级和免打扰避免通知轰炸。
- 偏好管理：让用户按类型、时间段和渠道控制通知接收方式。
- 系统架构：整合业务事件、调度、推送、站内信、缓存、队列和监控。
读完后，你应该能从用户体验和系统可靠性两个角度设计通知系统：既能把重要消息送达，也能避免重复、打扰和不可控的推送洪峰。