英雄联盟竞猜高峰期系统容量规划的实际教训

英雄联盟竞猜业务有一个显著特征：流量不是均匀分布的，而是随着赛事进程剧烈波动。小组赛阶段访问量相对平稳，进入淘汰赛尤其是焦点对决时，页面请求量可能在很短时间内翻数倍。许多技术团队在容量规划上踩过的坑，本质上都是把竞猜系统当成了普通 Web 应用来对待，忽略了赛事驱动的脉冲式流量规律。

容量评估是第一道关口。常见教训是只参考历史平均峰值，而忽略了单场焦点赛事叠加多玩法同时开放带来的瞬时压力。更合理的做法是按赛事阶段拆分流量模型，把页面浏览、数据查询、预测提交分别估算，再叠加一个安全系数。容量评估不是一次性的工作，赛程公布后就应该根据对阵热度和玩法开放节奏重新修正预估，而不是沿用上一阶段的结论。

弹性伸缩的滞后性是被低估的问题。云环境下的自动伸缩依赖监控指标触发，但流量爬升往往在几分钟内完成，而实例启动、服务注册、依赖预热都需要时间。如果伸缩阈值设置得过于保守，扩容动作会明显落后于流量增长。实际教训是：对竞猜核心链路应设置更灵敏的触发条件，并在重点赛事开始前主动预扩容，而不是完全依赖自动策略。

数据库往往是高峰期最先暴露的瓶颈。竞猜场景中，胜负预测、首杀预测等操作会集中产生写入请求，同时首页和赛事列表又带来大量查询。连接池耗尽和慢查询堆积是最常见的症状。容量规划时容易只关注应用层实例数量，而忽视数据库连接池上限、读写分离是否到位、高频查询是否建立了合理索引。压测时应该模拟真实混合读写比例，而不是只压读或只压写。

缓存策略的教训集中在热点数据失效上。赛事开始前，大量用户同时刷新赛事信息和预测状态，如果缓存集中过期，请求会瞬间回源到数据库，形成击穿。错峰过期、互斥重建、热点数据不过期等策略在平时看起来多余，在高峰期却是保命手段。缓存命中率的监控同样重要，命中率骤降往往是数据库压力上升的前兆。

降级预案的价值只有在真正演练过之后才能体现。很多团队写了降级方案，却没有在压力环境下验证过开关是否生效、降级后用户体验是否可接受。竞猜系统的降级应该分层设计：先关闭非核心的统计展示，再限制高频查询频率，最后才考虑对预测提交做排队或限流。每一层降级都需要明确触发条件和恢复流程，避免误操作。

从这些教训中可以提炼出一个基本判断原则：容量规划的核心不是买多少机器，而是理解流量从哪来、在哪里汇聚、哪个环节最先撑不住。英雄联盟竞猜的流量由赛程驱动，容量保障就应该围绕赛程做预判，把评估、扩容、压测、降级串成一条闭环。赛事热度会变化，玩法会迭代，但脉冲式流量下的容量保障逻辑是长期有效的。