这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
消息分级
分级是设计前提
弹幕系统的关键不是「每条消息都绝对可靠」，而是给不同消息分级。没有分级，系统会在高峰时无法取舍。
消息分级
不同消息不能一视同仁——这张表是系统的核心设计依据
| 消息类型 | 优先级 | 可靠性要求 | 示例 |
|---|---|---|---|
| 普通弹幕 | 中 | 低延迟优先，允许采样 / 少量丢失 | 用户评论、闲聊 |
| 系统公告 | 高 | 必须送达或重试 | 开播提醒、活动公告 |
| 礼物消息 | 高 | 以支付结果为准，幂等展示 | 送礼物、送礼动效 |
| 管理消息 | 最高 | 强审计、快速生效 | 禁言、踢人、清屏 |
| 点赞事件 | 低 | 聚合统计，不逐条广播 | 点赞、热度 |
为什么要分级
如果所有消息都按「必须可靠」处理：
- 每条都要落库、确认、重试 → 延迟变高。
- 高峰时队列被普通弹幕塞满 → 礼物、管理消息被拖死。
- 系统为了普通弹幕的可靠性，做得又慢又复杂。
分级让系统可以按类型做不同取舍：普通弹幕追求快和可用，付费与管理消息追求一致与可追踪。
分级带来的架构差异
| 级别 | 架构差异 |
|---|---|
| 普通弹幕 | 采样展示、可降级、允许丢 |
| 系统公告 | 独立高优通道、重试 |
| 礼物消息 | 以支付结果为准、幂等 |
| 管理消息 | 最高优先级、强审计 |
| 点赞事件 | 聚合计数、不逐条广播 |
后续每章的架构决策（队列、限流、重试、幂等）都源于这张分级表。
一句话
消息分级是直播弹幕系统的第一性设计：先回答「哪些必须可靠、哪些可以采样」，再谈 WebSocket、广播、队列这些具体方案。
下一章进入弹幕基础：房间、用户、消息三个核心对象。