某体育平台在赛季前两周做联调，赛事直播与互动社区同时上线。现场最直观的约束不是功能多少，而是带宽峰值、审核人力与并发写入在同一个时间窗里打架。这篇备忘只记录推演过程，不替任何方案背书。
场景设定：一个中小型体育平台，直播流走第三方源，互动社区自建。约束是预算有限、审核只有两人、开赛前无法做全量压测。下面按现场顺序展开。
现场信号：哪些苗头先看
联调第一天就要盯这些信号，不要等到开赛才看。
- 直播首帧时间波动：同一路源在不同网络下差异是否稳定。
- 互动社区发帖延迟：从提交到可见的耗时曲线。
- 弹幕与评论的写入队列长度：是否持续堆积。
- 审核后台待处理条数的增速：单位时间新增量。
- 同一账号在多端的登录态是否互相踢出。
这些信号共同指向一个判断：直播链路和互动链路是否在争抢同一批资源。
现场教训：把直播和互动社区放在同一台机器上做演示，很容易掩盖真实并发下的排队问题。
故障模式：赛事直播与互动社区常见断点
推演中反复出现的断点，大致归为四类。
- 直播侧：源切换后播放器未重连，画面停在上一场。
- 互动侧：热门赛事期间评论写入失败，但前端仍显示成功。
- 审核侧：关键词过滤误伤正常讨论，人工队列被挤爆。
- 账号侧：直播观看时长与社区等级不同步，用户看到两套数据。
这些断点单看都不致命，叠加在开赛前十分钟就会连锁。
诊断顺序：从入口到互动链路
诊断顺序建议固定，避免现场乱翻日志。
- 先确认直播入口可播：取一路源，验证首帧与切换。
- 再确认互动入口可写：发一条评论，观察返回与可见延迟。
- 然后看两者共用资源：带宽、连接数、数据库写入。
- 最后查审核链路：待处理队列是否与写入量匹配。
顺序颠倒的代价是：先修互动，直播已经掉线，用户直接离开。
回滚与恢复：先保哪一头
边界条件很明确：当并发超过预设阈值，必须决定牺牲哪一侧。
- 优先保赛事直播可看，互动社区降级为只读。
- 若直播源本身不稳，则保互动社区，直播切备用源并公告。
- 回滚顺序：先关非核心写入，再降审核并发，最后才动直播源。
- 恢复顺序相反：先恢复直播，再逐步放开互动写入。
回滚不是失败，是现场约束下的取舍。提前写好开关，比现场争论快得多。
复盘备忘：下次现场先查什么
把这次推演压缩成一份可带走的清单。
- 直播与互动是否共用同一批资源，峰值是否错开。
- 审核人力能否覆盖开赛前十分钟的写入量。
- 降级开关是否可独立控制直播与互动社区。
- 账号数据同步是否有明确的一致性边界。
- 回滚与恢复顺序是否写进值班手册。
体育平台的一线工作，多数时候不是选哪个功能，而是先确认约束、再推演边界、最后留好回滚。下次现场，先看信号，再看顺序。 赛事直播