题目重点：设计大规模直播评论、点赞与实时分发，说明SSE、消息序列、扇出合并和断线恢复。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练目标是直播房间评论流，允许有界延迟；每房间顺序由服务器序列确定，跨房间不需总顺序。是否所有评论都展示或只展示采样需先问。
- 写者需鉴权与限流；审核失败的评论不能传播。删除/撤回也是带版本事件，重连不能让被删除内容重新出现。
- 示例房间10万观众、1000评论/秒、每事件500B。全部广播约50GB/秒payload，尚未计协议开销与复制。
解题路线
- POST comment保存roomId/userId/commentId/content及审核状态，requestId去重；审核通过后在room分区生成sequence并发布。数据库是可恢复事实，pubsub负责实时分发，不只依赖临时channel。
- Gateway维持SSE或WebSocket长连接，按房间订阅分发；SSE适合服务器单向评论流，发送评论仍HTTP。连接路由和重连会话不等于消息持久化。
- 热门房间分层广播到多个gateway，每gateway批量发送。若客户端展示能力只有几条/秒，合并/抽样并明确UI策略；完整评论保留查询接口，不能声称抽样仍送达每条。
- 重连带lastSequence，在短期日志窗口补发；超窗口先快照再续订，以snapshotSequence作为水位避免快照与直播之间丢事件。事件ID去重，序列缺口触发replay。
- 对慢消费者限制队列字节数，超限断开并提示重连；无界队列会吃光gateway内存。删除事件优先传播并在读取中复核权限，防止离线缓存泄露。
手动走一遍
快照到seq100，订阅先缓冲101之后事件；快照渲染完依次消费101+。若先快照再新建订阅，期间seq101可能永久漏掉。用户重试POST两次只产生一个commentId和一条有效评论。
规模与取舍
房间分区写入O(1)追加，真正成本为扇出B×R×V；网关内存约连接数×连接开销+有界队列。必须分别预算写QPS、活跃长连接、出网字节、持久日志保留期。
易错点与追问
容易失分的边界
- pubsub消息丢失后没有sequence与replay无法弥补；长连接不断不代表消息不丢。
- 慢消费者全量缓存无上限会导致房间连锁故障。
- 点赞总数与单条评论顺序不是同一一致性问题，可异步计数但需去重用户状态变化。
继续深挖
- 审核耗时会打乱原始提交顺序；按通过时间排序还是保留提交序列占位，需要明确产品体验。
- 多地区房间主写区失联时是暂停出价式写入还是容忍评论局部顺序？给出可用性与顺序取舍。
