这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
系统架构 - 完整的通知系统
三个月的成长
不知不觉，我在”圈内”已经三个月了。
回想第一天接手通知系统时的问题：
- 推送延迟 5-10 秒
- 重复推送
- 半夜打扰用户
- 没有偏好设置
现在，这些问题都已经解决了。
完整架构
我画了一张完整的系统架构图：
┌─────────────────────────────────────────────────────────────────┐
│ 业务层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 评论服务 │ │ 点赞服务 │ │ 关注服务 │ │ 私信服务 │ │
│ └─────┬────┘ └─────┬────┘ └─────┬────┘ └─────┬────┘ │
│ └──────────────┴──────────────┴──────────────┘ │
└──────────────────────────────┼───────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ 通知服务层 │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 通知调度服务 │ │
│ │ - 接收业务事件 / 检查用户偏好 / 限流检查 / 消息聚合 │ │
│ └───────────────────────┬──────────────────────────────────┘ │
│ ┌───────────┴───────────┐ │
│ ▼ ▼ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ 推送服务 │ │ 站内信服务 │ │
│ │ - APNs/厂商推送 │ │ - 消息存储/查询 │ │
│ └──────────────────┘ └──────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ MySQL │ │ Redis │ │ RabbitMQ │ │ ES │ │
│ │ 消息存储 │ │ 缓存/限流│ │ 消息队列 │ │ 日志搜索 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────┘关键技术决策
1. 消息队列：RabbitMQ
支持延迟队列、消息确认、优先级队列
2. 缓存：Redis
用户偏好缓存、未读计数、推送限流、分布式锁
3. 数据库：MySQL 分表
站内信表按用户 ID 分 16 张表
高可用设计
- 服务降级：推送服务不可用时，只发站内信
- 消息重试：推送失败自动重试 3 次
- 监控告警：延迟、成功率、投诉监控
性能优化
- 批量操作：批量创建站内信
- 异步处理：Celery 异步发送推送
- 连接池：HTTP 连接复用
关键指标
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 推送延迟 | 5-10 秒 | < 1 秒 |
| 推送成功率 | 85% | 95% |
| 重复推送率 | 5% | < 0.1% |
| 系统可用性 | 95% | 99.9% |
经验总结
- 理解业务场景：平衡及时性和打扰度
- 分层设计：业务层、服务层、数据层独立演进
- 用户控制：让用户自己控制通知偏好
- 监控驱动：没有监控就是盲人摸象
技术栈
- 后端：Python / PHP
- 消息队列：RabbitMQ
- 缓存：Redis
- 数据库：MySQL（分表）
- 监控：Prometheus + Grafana
- 推送：极光推送 / 自建推送
- 任务队列：Celery
通知系统看起来简单，但要做到及时、可靠、不打扰，需要深入理解业务，精心设计架构。希望这门课程能帮助你设计出自己的通知系统！