赛事直播与实时数据：延迟压到多少才够用

先定延迟分级

「实时」不是越快越好，是分级按需。参照行业常见做法：

比分直播数据走长连接，事件统计走秒级，榜单类走缓存——三档分开，成本比全走长连接低一半以上。判断自己的产品该压到哪一档，先看用户画像：以跟赛为主的用户，毫秒级比分是刚需；以赛后浏览为主的用户，秒级完全够用，别为想象中的需求买单。

推送链路设计

标准三段式：数据源 → 消息队列 → 推送网关。两个关键设计：第一，消息队列做削峰，比赛日瞬时比分事件能堆到每秒几千条，队列先接住再匀速消费；第二，推送网关按「赛事房间」分组，用户订阅具体赛事而不是全局广播，焦点比赛的推送量能压一个数量级。房间模式的扩容细节，配合赛事峰值的高并发应对一起看。

视频流和数据流的配合

视频直播延迟通常 5-30 秒，比分推送常常比画面还快——用户听到欢呼再刷手机，比分还是 0-0，投诉就来了。解法是给数据加可配置延迟缓冲，让比分变化落在视频画面之后 1-2 秒——用户先看到进球画面再看到比分跳动，体验反而更好。缓冲时长按视频延迟实测值配，别拍脑袋。

成本怎么算

实时链路的成本大头是长连接数：每个在线连接占用网关内存，峰值并发 10 万连接就需要专门规划网关集群。三档分级的价值在这里体现——如果积分榜、赛程这类分钟级内容也走长连接，连接数直接翻倍，账单也翻倍。另一个省钱位置是推送内容瘦身：比分事件只推变更字段不推全量，带宽能省六成。

弱网兜底

• 长连接断开自动降级为轮询，间隔从 3 秒起步自适应上调。
• 移动网络下图片与统计模块懒加载，比分条优先渲染。
• 终场后 10 分钟内数据进修正窗口，推送「确认比分」而非实时值。
• 断线重连只补增量事件不重放全量，重连风暴时网关压力可控。

呈现层怎么把实时数据用好的基础是数据源质量，选型方法见体育数据源接入与选型要点；用户在手机上怎么接住这些实时信息，见体育移动端体验设计。