活动开始后的负载通常不是均匀上涨：公告推送、玩家集中登录、组队匹配和奖励领取，可能先后形成不同压力点。做好游戏活动期间弹性扩容策略，重点不是一味增加机器，而是判断哪类服务先达到瓶颈、扩容需要多久，以及负载回落后何时安全缩容。
先画出活动负载的时间线
以限时副本开放为例，玩家可能在开放前集中登录，开场时请求角色与活动状态，随后进入匹配和战斗，结束后再集中领取奖励。登录服务、匹配服务、战斗逻辑和奖励接口的峰值并不同步。把活动日程对应到各服务的请求量、并发连接、排队长度和响应延迟，才能找到真正需要扩容的环节。
制定峰值预测时，可参考同类型活动的历史曲线、预约或通知安排、版本更新规模，以及当前在线人数。历史数据只适用于相近的活动形式和版本环境；玩法、客户端版本或营销触达变化较大时，应提高安全余量，并用小规模压测校验假设。
按服务层级安排扩容
先扩容可快速复制的服务
无状态的登录网关、活动查询接口等，通常适合通过增加实例分担请求；具体能否横向扩展，还要检查会话是否外置、数据库连接是否有限制。匹配队列、消息处理等服务则要观察积压量和消费速度，单看实例数量或处理器利用率，可能看不出排队正在恶化。
谨慎处理有状态环节
数据库、分布式缓存和战斗房间等状态服务，扩容不一定能立即分摊已有负载，还可能增加数据迁移、连接争用或状态同步成本。应先确认瓶颈来自查询、写入、锁竞争还是连接数，再选择读写分离、缓存策略调整或增加处理节点；避免在活动高峰临时进行高风险拓扑变更。
自动伸缩可作为执行工具，而不是负载判断的替代品。以 Kubernetes HPA 为例，可依据利用率或自定义指标调整工作负载副本；若指标采集延迟、启动慢或扩容上限设置不合理，策略就难以跟上突发流量。因此，游戏活动期间弹性扩容策略应同时规定目标指标、最小与最大副本数，以及扩容失败时的人工兜底方式。
从预热到回收的操作步骤
- 活动前梳理依赖。列出入口、核心业务、队列、存储和外部服务，标明扩容是否需要预留配额、预热缓存或增加连接池容量。
- 设置分层阈值。除请求延迟外，加入排队长度、错误率和每实例并发等指标。阈值应以压测及历史基线确定；利用率阈值可先在约60%至70%的区间验证，但不同实例规格和业务类型差异很大，不能直接照搬。
- 提前容量预热。根据实例启动、镜像拉取和缓存填充耗时，安排活动前预扩容。常见服务若启动需数分钟，就应留出相应提前量；实际时间以环境演练为准。突发活动可保留一部分暖实例，减少冷启动造成的延迟。
- 活动中分批调整。先增加最可能受压的服务，观察请求延迟、错误率和下游连接，再继续扩容。若上游变快而数据库已饱和，应限制请求、启用排队或降级非核心功能，避免把压力传给依赖层。
- 负载回落后缓慢缩容。设置冷却时间，要求关键指标持续低于回收阈值一段时间再减实例。可从数分钟到十几分钟的观察窗口开始测试；活动结束、玩家短暂离开或奖励结算时，仍可能出现二次峰值。
用演练结果校准策略
压测应覆盖集中登录、匹配积压、奖励集中领取等不同阶段，并记录扩容触发到实例可用的时间。若扩容后延迟仍高，检查数据库、缓存、网络连接或第三方依赖是否才是瓶颈；若实例启动完成时峰值已过，则应提前触发或保留基础容量。活动结束后复盘预测偏差、扩容耗时、告警和资源回收情况，再调整下一次配置。
最终，游戏活动期间弹性扩容策略要让资源变化跟随业务阶段，而不是只追着单一指标跑：提前预测与预热，按服务层级扩容，确认下游承载能力，再以稳定观察窗口回收资源。
常见问题
只看在线人数够吗？
不够。在线人数不等于请求压力，应同时看请求速率、排队长度、延迟、错误率和关键依赖状态。
扩容阈值应该设多少？
没有适用于所有服务的固定值。用压测和历史基线确定，并为扩容启动时间、指标延迟及活动波动留出余量。
活动结束后能立刻缩容吗？
通常不宜立刻回收。待登录、结算和奖励请求等指标持续回落，再按批次缩容，并保留应对二次峰值的容量。