赛事峰值：短跑接长跑的架构题

先看清峰值画像

足球焦点战的典型流量曲线：开赛前 60 分钟开始爬坡，开赛哨响冲到峰值的六成，此后随攻防节奏波动，进球瞬间再叠一个尖峰（能到日常的 15 倍），中场休息回落到五成，终场后又起一个看集锦的小峰。峰值QPS到几万量级是常态。

两个推论：扩容要跟着时间轴走，不是匀速加机器；进球尖峰必须靠缓存和连接复用扛，靠临时扩容来不及——从告警到实例就绪最快也要两三分钟，尖峰只有几十秒。

扩容节奏

• T-2小时：按预估峰值容量的 70% 预热扩容，别等流量来了再加。
• T-30分钟：推送网关与长连接服务扩到位，这两块扩容最慢、故障最疼。
• 比赛进行中：只做自动扩容（按 CPU 和连接数触发），人工变更冻结——比赛日改配置是事故的头号来源。
• 终场后 1 小时：确认集锦峰过了再缩容，缩早了比不缩还难受。

三道防线

1. 数据库写入：比分事件先入消息队列再批量落库，写入 QPS 削掉一个数量级。比赛进行中的表只存事件流，积分榜等衍生数据异步结算。
2. 读缓存：比分页的多级缓存——本地缓存 3 秒、Redis 5 秒、回源加互斥锁。焦点比赛的比分读取，九成以上请求终结在本地缓存。
3. 推送房间：按赛事分房、房间内再按比分/事件/统计分频道。用户断线重连只补拉当前房间增量，不重放全量。

压测怎么做才有效

压测要模拟真实时间轴：从 T-2 小时的爬坡开始加压，进球瞬间用脉冲流量模拟（瞬时拉到目标峰值的 120%），持续 30 秒再回落。只压匀速高峰不压脉冲，等于没测——出问题的从来都是尖峰那几十秒。压测数据留档，每个赛季开赛前用最近的真实峰值重新校准一次目标容量。

降级预案

降级要提前写死触发条件：长连接数超容量 80% 时新用户转轮询；数据库延迟超 2 秒时停统计模块保比分；数据源断流 5 分钟时页面明确提示「数据延迟」而不是假装正常。降级顺序的原则是保主干砍枝叶：比分和赛程是主干，统计、集锦是枝叶，砍的顺序从枝叶开始。预案的比赛日演练至少做一次，没演练过的预案等于没有。房间的推送架构见赛事直播与实时数据方案，数据源的故障补偿见体育数据API对接细节。