突发流量场景：先压测并定位瓶颈，再确定扩容方案

📈 突发流量场景：先压测并确定扩容方案

突发流量的风险不仅是实例CPU不足，还包括请求排队、连接池耗尽、数据库写热点、缓存冷启动和扩容生效延迟。扩容前要先复现负载并找出首个限制，再验证扩容动作能否及时增加有效处理能力。容量目标应由用户体验与依赖承载能力共同定义。

🔎 一、设计有代表性的压测

明确目标峰值并发、请求到达速率、读写比例、数据集大小、缓存冷热状态和响应时间目标。把登录、查询、写入、上传及后台任务按生产比例组合；只压首页会遗漏昂贵查询和写入冲突。压测客户端要有足够并发和网络能力，避免客户端先饱和而误判服务端容量。

测试数据应接近生产工作集，覆盖缓存预热与冷启动。将外部依赖纳入测试，或以受控方式模拟其时延，避免依赖被压垮造成结果不可解释。记录压测版本、配置、数据量、请求脚本和时间窗口，确保复测可比较。

🧭 二、用饱和拐点定位首要瓶颈

从低并发逐档增加负载，每档维持到队列和缓存基本稳定。观察吞吐、P95/P99、错误率、CPU、内存、磁盘延迟、网络流量、线程池与连接池等待。sar -u 1可辅助观察CPU利用趋势，但需同时查看应用和依赖指标。

• 吞吐不再增长、延迟陡升：系统进入排队区域，找出同期增长的资源或等待队列。
• CPU饱和且可并行请求增多：评估增加实例或优化热点代码，并确认依赖能承接流量。
• 连接池等待或数据库延迟上升：扩应用实例可能增加连接洪峰，应先控制并发、优化查询或处理热点。
• 磁盘队列与写入等待增长：检查持久化路径，不能仅通过横向扩容应用解决。

单看总请求数或平均延迟会隐藏尾延迟和错误激增，应把拐点与业务目标关联。

📊 三、为不同瓶颈选择动作

横向扩展适用于请求可并行、状态外置且入口能分发流量的应用；纵向扩展适用于单实例资源确实不足且应用暂时不能拆分的情况。缓存应作用于可重复读取的数据，并定义失效策略；限流用于保护关键依赖；队列适合可以异步完成的任务。

扩实例前检查连接池大小是否按副本数成倍增加，防止数据库被新增并发击穿。扩容阈值需结合延迟、队列或资源趋势，设置冷却时间、最大实例边界和过载保护，避免来回振荡。扩容无法修复代码错误或单一共享依赖容量不足。

✅ 四、验证自动扩容与恢复过程

1. 测量从触发条件满足到新实例完成启动、健康检查并接流量的时间。
2. 在新旧副本并存时观察连接总量、缓存冷启动和依赖负载。
3. 使用相同负载比较扩容前后的吞吐、尾延迟和错误率。
4. 流量下降后确认缩容不会过早移除正在处理任务的副本。
5. 验证达到最大边界时的限流、排队或降级行为。

常见误区是用固定实例数压测后便宣称自动扩容有效，或只看扩容成功事件而不检查新实例是否真正接流量。记录触发指标、就绪耗时、容量上限和过载结果，才形成可操作的扩容方案。⏱️