题目重点：设计直播评论入口、房间序号、热场分片与观看者扇出，解释何时使用日志型队列及降级策略。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版用户可给一场 liveStreamId 发文字评论，观众看到允许的评论；发言和观看要有身份/权限与速率限制。
- 单房间内尽量保持可解释的顺序，每条已接受评论有 roomSequence；跨房间无全局顺序。
- 审核有同步硬阻断与异步复审；具体策略、法规与延迟目标由产品定义。
解题路线
- 入口验证用户身份、直播间状态、禁言/屏蔽、速率和文本大小，赋 clientMessageId 幂等键；接受结果与最终可见状态区分。
- 同房间经稳定分区或 sequencer 分配递增 roomSequence，写 durable 日志/存储；若高热点单分区成为瓶颈，可拆多个子流并接受显示顺序弱化，或由 room aggregator 合并有界窗口，明确取舍。
- 审核先同步挡明显恶意内容，复杂模型异步复审可撤销已展示评论；撤销事件带 commentId 与版本推到观看者，历史查询同样过滤。
- 评论存储和观众分发分开：日志供重放与异步消费，边缘 WebSocket/SSE fanout 节点订阅热房间并向本地观众广播；百万观众不应导致入口为每个观众写一条持久消息。
- Kafka 类日志适合高吞吐、按 key 顺序和多消费者重放；普通队列可能更适合任务分发/确认。选择依据是重放、保留、热点 key、消费者拓扑和运维成本，不是因为‘直播必须 Kafka’。
- 慢客户端给有界缓冲，溢出时丢旧非关键评论并提示跳到最新；历史回补用 roomSequence 游标。观测入口延迟、审核滞后、热房间扇出、丢帧/重连和成本。
手动走一遍
房间 R 每秒 10,000 条评论、100 万观看者。入口写每条一次持久事件，再由多个边缘节点向各自连接扇出；若把每条评论直接持久写给 100 万人，会放大为每秒 100 亿条。某评论复审被删除后，边缘收到同 id 的撤销事件，客户端移除它。
规模与取舍
评论写入 O(C)，边缘实际网络扇出 O(C×V) 仍是物理下界（若每位观众都看每条），可通过采样、排名、合并和区域分发控制；持久存储不必 O(C×V)。单房间严格序号需串行化或预留号段，最热房间上限是关键。
易错点与追问
容易失分的边界
- 所有房间共用一个分区，热点房间拖垮全站。
- 入口对每个观看者各写一次持久队列。
- 异步审核删除后仅改数据库，不通知已展示客户端。
- 随意跨分区仍承诺完全严格房间顺序。
- 以产品名而非需求解释 Kafka 选择。
继续深挖
- 热门房间如何做慢模式和采样而保留主播互动？
- 断线重连时怎样用序号补洞、处理被撤销评论？
- 跨区域观众的延迟和顺序如何权衡？
- 审核模型故障时是否暂停展示未审评论？
