二级无损缓存队列需l1环形队列与l2 redis streams在丢包边界、背压信号、重放语义上严格对齐：l1须预分配、原子操作、满时丢新包并告警；l2按房间分片、限长设ttl、仅作补播通道，二者通过溢出移交而非定时dump协同。
二级无损缓存队列不是加一层就完事，而是必须让环形队列（L1）和 Redis Streams（L2）在丢包边界、背压信号、重放语义上对齐，否则 L2 只会放大延迟或掩盖真实丢包点。
环形队列（L1）必须显式暴露满/空状态并触发背压
UDP 弹幕接收 goroutine 不能依赖 channel 阻塞来“自然限速”，那会导致 socket buffer 溢出丢包。L1 必须是预分配的 [BUFF_MAX][BUFF_LEN]byte 环形结构，用 sync/atomic 操作 head 和 tail：
- 入队前检查是否满：
if (tail+1)%capacity == head→ 记录dropped_count并跳过写入（新包丢弃策略） - 禁止用 “牺牲一个槽位” 判断法，它增加竞态风险且对弹幕业务无实际收益
- 出队不 copy 数据，直接返回
buf[head][:n]切片引用，避免 GC 和内存拷贝开销 - 满时必须立刻向监控系统上报，而非静默丢弃——
queue_usage_ratio > 95%连续 10 秒应触发告警或自动扩容
Redis Streams（L2）不能当普通消息队列用，要按房间分 shard + 设置 TTL
L2 不是用来兜底所有弹幕的，而是为「可重放、需审计、低频消费」场景服务。若全量写入 Streams，会因单 stream 写入瓶颈和消费者 lag 导致广播延迟飙升：
- Stream key 必须带房间 ID，例如
barrage_stream:room_123456，避免热点 stream - 每条消息用
XADD写入时，显式指定MAXLEN ~5000（非~模式），防止无限增长拖垮 Redis - 设置
EXPIRE barrage_stream:room_123456 3600，一小时后自动清理，避免冷数据堆积 - 广播服务从 Streams 拉取时，必须用
XREAD BLOCK 100 STREAMS barrage_stream:room_123456 $，不轮询、不空转
L1 与 L2 的衔接必须靠明确的“溢出移交”逻辑，而非定时 dump
环形队列满 ≠ 立即 dump 全部内容到 Redis。那样会破坏顺序、引入重复、且无法区分“该丢的新包”和“该保的老包”：
- 只在 L1 满且持续 3 秒以上时，才将 L1 中最老的
200条（非全部）移交至 L2，保留最新弹幕在内存中优先广播 - 移交动作由独立 goroutine 执行，带
context.WithTimeout(ctx, 500*time.Millisecond)，超时则放弃，不阻塞主接收流 - L2 写入成功后，更新 L1 的
head（原子操作），表示这批已持久化；失败则重试一次，再失败就记录 error 并继续 - 绝不允许 L2 成为 L1 的“备份盘”，它的角色是「补播通道」，不是「主缓冲」
真正难的不是实现两级队列，而是定义清楚每一级的职责边界：L1 负责毫秒级吞吐与确定性丢弃，L2 负责分钟级重放与审计溯源。一旦混淆，比如把 L2 当作防丢主力，就会在高并发下出现大量 NOGROUP 或 TIMEOUT 错误，而真实丢包早已发生在 UDP 层，根本没进过任何队列。
