这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
三阶段
通知系统的核心是什么
午饭时间，我在工位上思考通知系统的本质。
我想起一篇论文，把通知系统拆解为三个阶段：
通知系统的三个阶段
产生阶段业务事件触发通知用户 A 评论了用户 B 的动态，生成一条通知
→存储阶段消息队列 + 持久化记录通知类型、内容、接收者、状态
→投递阶段多渠道分发选择渠道，发送推送，更新状态
关键认知：
当前的旧系统把三个阶段混在一起，耦合度过高——
轮询脚本既要查库、又要发送、还要更新状态，任何一个环节变慢都会拖垮整体。拆开三阶段是重构的第一步。
三阶段的分工
| 阶段 | 做什么 | 典型组件 |
|---|---|---|
| 产生阶段 | 业务事件触发通知 | 评论 / 点赞 / 关注服务 |
| 存储阶段 | 消息队列 + 持久化 | RabbitMQ + 数据库 |
| 投递阶段 | 多渠道分发 | 推送服务 / 站内信 |
为什么拆开是关键
当前的旧系统把三个阶段混在一起：
- 轮询脚本既查库（存储）、又发送（投递）、又更新状态（存储）。
- 任何一个环节变慢都会拖垮整体。
- 无法独立扩展：发送慢不能只加发送实例。
拆开三阶段，才能让每一环独立演进、独立扩展、独立容错。
两阶段 vs 三阶段
一个常见的思考是「两阶段」（产生 + 投递），但存储阶段不可或缺：
- 站内信需要持久化（历史可查）。
- 推送失败需要重试（状态存储）。
- 审计需要留痕（谁收到了什么）。
存储阶段是可靠性的基石——它让「发不出」变成「待重试」，而不是「永久丢失」。
一句话
通知系统的本质是「产生 → 存储 → 投递」的三阶段流水线。当前系统把它们混在一起，所以处处是问题。拆开三阶段，是重构的第一步。
发现内容有问题？
告诉我们哪里需要改进。