这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
设计原则
设计通知系统的三个月，让我总结出几条可以复用到其他系统设计的原则。
1. 分层解耦
原则
让"发生了什么"和"怎么通知"彻底分开。实践
业务服务只产生事件，通知系统负责投递。这样评论、点赞、关注、私信可以接入同一个通知链路，新增业务也不需要改动通知核心。
- 业务层：产生
comment.created等事件 - 调度层：决策”要不要发、怎么发”
- 投递层：执行推送和站内信
2. 异步削峰
原则
不要在业务请求链路上同步做高延迟的事。实践
推送、站内信写入都通过消息队列异步执行。业务接口只负责”接单”，通知在后台慢慢处理。这样即使某段时间通知量暴涨，也不会拖慢业务接口。
3. 用户控制优先
原则
用户对接收频率的诉求，优先于"尽量多送达"。实践
通知系统容易犯的错误是只追求送达率，结果变成骚扰。正确做法是把偏好管理前置：全局开关、分类开关、免打扰时段、推送频率，都让用户自己控制。限流和聚合，本质都是在替用户过滤打扰。
4. 幂等与重试
原则
投递可能失败，但绝不能重复或丢失。实践
推送失败自动重试 3 次，配合死信队列兜底；同时用通知 ID 做幂等，防止消息队列重复消费导致同一通知推多次。站内信写入也做幂等，重复事件不会产生重复消息。
5. 状态可追溯
原则
每一条通知，都要能回答"现在到哪一步了"。实践
通知从产生到送达有完整状态机：待发送 → 已发送 → 已到达 → 已读。每个环节都记录时间和结果。这样排查”用户为什么没收到”时，能精确到是调度没触发、推送失败，还是用户没打开。
6. 监控先行
原则
没有监控的通知系统是盲目的。实践
上线第一版就该有最基本的监控：推送延迟、成功率、重复率、投诉率。指标驱动优化，而不是靠感觉。投诉率比送达率更能反映用户体验。
7. 按需聚合
原则
相似的通知合并，保留信息，减少打扰。实践
一个热门动态可能有上千个赞，逐条通知会把用户淹没。用”张三等 15 人点赞了你的动态”这种聚合方式，既让用户知道发生了什么，又不制造噪音。聚合是限流的前置手段，两者配合使用。
8. 渐进式演进
原则
从简单方案开始，被问题推着升级，而不是一次设计到位。实践
通知系统一开始只是 PHP 轮询脚本，后来才逐步演进出消息队列、推送服务、站内信、偏好管理和多端同步。每个复杂度都是被真实的用户投诉和业务问题逼出来的，而不是提前堆上去的。
系统设计 checklist
功能性：
✓ 通知类型完整（评论/点赞/关注/私信/系统）
✓ 推送与站内信双通道
✓ 已读/未读/多端同步
性能：
✓ 推送延迟可接受
✓ 异步削峰，业务链路不受影响
✓ 未读计数高频查询优化
可靠性：
✓ 推送失败自动重试
✓ 幂等防重复
✓ 服务降级（推送挂了只发站内信）
可维护性：
✓ 分层清晰，职责单一
✓ 状态可追溯
✓ 监控告警
用户体验：
✓ 偏好管理（分类/时段/频率）
✓ 限流防骚扰
✓ 消息聚合减少打扰记住：
- 通知系统是”及时送达”和”不打扰”之间的平衡
- 让用户自己控制，永远比系统替他决定更安全
- 简单方案能满足需求时，就不要提前引入复杂度