这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
限流防骚扰 - 避免通知轰炸
用户投诉：通知太多了
入职第五周，客服给我转了一条用户投诉：
“你们 App 太烦了！每分钟都给我发通知，我都要疯了！能不能关掉？”
我查了一下这个用户的通知记录：
数据设计要点
- 查询目标是快速定位状态、任务或资源，避免在关键路径上做大范围扫描。
type count MIN(created_at) MAX(created_at)
like 127 2026-04-01 09:00:00 2026-04-01 09:59:00
comment 45 2026-04-01 09:05:00 2026-04-01 09:58:00
follow 3 2026-04-01 09:10:00 2026-04-01 09:50:001 小时内，这个用户收到了 175 条通知！平均每分钟 3 条。
我打开这个用户的动态，发现是一条关于”如何学习编程”的帖子，引发了大量讨论：
- 127 个点赞
- 45 条评论
- 3 个新关注
每条点赞、评论都触发了通知，用户被淹没了。
问题分析
我分析了一下，发现通知系统缺少限流机制：
触发通知的场景：
- 每个点赞 → 1 条通知
- 每条评论 → 1 条通知
- 每个关注 → 1 条通知
热门动态可能：
- 点赞数：上千
- 评论数：上百
- 关注数：几十
如果每条都发通知，用户会收到几百条通知！核心问题：没有通知限流，热门内容会轰炸用户。
限流策略
我调研了几个方案：
方案 A：固定阈值限流
每个用户每小时最多接收 N 条通知：
用户每小时最多 20 条通知
超过 20 条，暂停发送优点：简单 缺点：一刀切，无法区分重要通知
方案 B：按类型限流
不同类型的通知，有不同的限流规则：
点赞：每小时最多 5 条
评论：每小时最多 10 条
私信：不限流（重要）优点：灵活 缺点：需要手动设置每种类型的阈值
方案 C：聚合 + 限流
相似通知聚合，再加上限流：
点赞：同一动态的点赞，聚合成 1 条（"张三等15人点赞了你的动态"）
同一动态每小时最多 1 条点赞通知
评论：同一用户的连续评论，聚合成 1 条
同一动态每小时最多 5 条评论通知
私信：不聚合，不限流优点：减少通知数量，同时保留重要信息 缺点：实现复杂
我选择了方案 C（聚合 + 限流），因为它既减少了通知数量，又保留了关键信息。
限流实现
1. 点赞限流
点赞通知有两个问题：
- 数量多（热门动态可能有上千个赞）
- 内容单一（都是”某人点赞了你的动态”）
我设计了聚合 + 时间窗口限流：
2. 评论限流
评论比点赞复杂：
- 不同用户评论，内容不同
- 同一用户连续评论，可以聚合
我设计了两层限流：
3. 推送限流
站内信限流了，但推送呢？
推送更需要限流，因为：
- 推送会打断用户
- 推送显示在通知中心，数量有限
- 推送过多会被用户关闭通知权限
我设计了推送限流：
不同通知类型的限流规则
我总结了一张限流规则表：
| 通知类型 | 站内信限流 | 推送限流 | 聚合规则 |
|---|---|---|---|
| 点赞 | 同一动态每小时最多 1 条 | 同一动态每小时最多推送 1 次 | 聚合成”张三等15人点赞” |
| 评论 | 同一动态每小时最多 5 条 | 同一动态每小时最多推送 3 次 | 同一用户5分钟内评论聚合 |
| 关注 | 不限流 | 每小时最多推送 5 次 | 不聚合 |
| 私信 | 不限流 | 不限流 | 不聚合 |
| 系统通知 | 每天最多 3 条 | 每天最多推送 1 次 | 不聚合 |
用户自定义限流
产品经理小李提出：“能不能让用户自己设置接收频率？”
我设计了用户偏好设置：
存储在数据库：
数据设计要点
- 核心是在
notification_preferences里保存业务事实，而不是把规则散落在应用逻辑里。- 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
在发送通知时检查用户偏好：
批量通知合并
对于系统通知（如促销、活动），我们需要批量发送，但要避免轰炸：
监控与告警
我添加了通知监控：
小结
这周我学到：
- 通知轰炸问题：热门内容会产生大量通知，淹没用户
- 限流策略：聚合 + 时间窗口限流，减少通知数量
- 不同类型限流：点赞限流严格，私信不限流
- 推送限流：推送比站内信更需要限流
- 用户偏好：让用户自定义通知接收频率
- 批量发送：系统通知分批发送，避免冲击
限流是通知系统的重要功能，平衡了及时性和用户体验。