这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
积压处理
积压从哪来
大促或热门直播（顶流开播）会造成队列积压：
- 入站速率超过消费速率。
- 下游（落库、审核）变慢。
- 某个环节故障。
积压不可怕，可怕的是没有预案。
积压处理策略
| 策略 | 做法 |
|---|---|
| 丢弃低优先级 | 普通弹幕队列超阈值时丢弃低优消息 |
| 保实时 | 落库队列延迟时先保证实时分发 |
| 礼物独立扩容 | 礼物队列单独扩容，避免被普通消息影响 |
| 监控告警 | 消费延迟进入告警，触发限流或降级 |
分级降级
关键认知：不是所有消息都值得保。
- 普通弹幕：积压时先丢，用户无感。
- 礼物 / 管理消息：不丢，走高优通道。
- 落库：可以延迟，但最终要追上（回放不能永久缺数据）。
积压的量化监控
- 队列积压量（当前待处理消息数）。
- 消费延迟（最新消息进入多久还没被消费）。
- 各队列分开展示，不能只看总数。
降级的触发与恢复
- 触发：积压超阈值 → 自动降级（丢普通、限流）。
- 恢复：积压消化后 → 恢复全量。
- 手动兜底：关键活动前评估容量，必要时提前扩容。
一句话
积压处理 = 分级降级（丢普通保高优）+ 独立扩容（礼物快车道）+ 量化监控。让系统能承受峰值，又不会让重要消息陪葬。
下一章礼物系统——更强一致性的互动消息。
发现内容有问题？
告诉我们哪里需要改进。