参与过的高并发系统项目，请分享在交易高峰期（如新股申购、重要事件发布）的扩容策略，包括如何快速增加服务器资源，以及如何保证业务连续性。

1) 【一句话结论】在交易高峰期，通过“预置资源池+动态弹性扩容”快速增加服务器资源，结合“蓝绿部署+服务降级”保障业务连续性，核心是“快速响应+业务无感知”。

2) 【原理/概念讲解】

• 预置资源池：提前在云平台（如阿里云/AWS）启动并保持一定数量的备用实例，高峰时无需等待启动，直接投入服务，类似餐厅提前准备桌椅，避免高峰时排队。
• 动态弹性扩容：系统根据实时指标（如QPS、CPU利用率）自动增加/减少实例，成本优化，类似餐厅根据客流自动增减桌椅。
• 蓝绿部署：部署新版本（绿）到新实例，通过流量路由逐步切换到新版本，若异常则回滚到旧版本（蓝），保证无中断，类似换桌布但保留旧桌布。
• 服务降级：高峰时简化非核心功能（如减少日志记录、关闭非必要API），保障核心交易（如新股申购）的可用性，类似高峰时先让核心用户用基本服务。

3) 【对比与适用场景】

方式	定义	特性	使用场景	注意点
预置扩容	提前启动并保持备用实例	响应快（实例已就绪）	高频突发流量（如新股申购）	成本较高，资源利用率低
动态扩容	根据负载自动启动实例	成本低，资源利用率高	持续波动流量	响应时间较长（需启动实例）
蓝绿部署	双版本并行，逐步切换流量	快速回滚，无中断	高可用场景	需双倍资源
金丝雀发布	逐步切换流量（1%→10%）	资源利用率高，风险低	持续迭代场景	切换时间长

4) 【示例】
假设使用AWS，监控流量用Prometheus，当QPS超过阈值（如10000），触发CloudWatch事件，调用AWS Auto Scaling增加EC2实例。伪代码：

# 监控逻辑（伪代码）
if prometheus.get('qps') > 10000:
    auto_scaling.scale_out(2)  # 增加两个实例
# 蓝绿部署
# 1. 部署新版本到新实例（绿）
# 2. Nginx配置：upstream green_servers { server 10.0.0.2:80; server 10.0.0.3:80; }
# 3. 逐步切换流量（如通过权重或DNS轮询）
# 4. 若健康检查（如检查API返回码200）失败，回滚到旧版本（蓝）
# 服务降级配置：高峰时关闭非核心API（如用户画像查询），仅保留核心交易API  

5) 【面试口播版答案】
在交易高峰期，我们采用“预置资源池+动态弹性扩容”结合“蓝绿部署+服务降级”的策略。首先，提前在云平台配置资源池（比如AWS的预置实例），确保高峰时能快速启动。当监控到QPS超过阈值（比如新股申购时可能达到10万+），系统自动触发扩容，调用云厂商API增加服务器实例。同时，为了保证业务连续性，采用蓝绿部署：先部署新版本到新实例（绿），通过Nginx的upstream模块逐步将流量切换到新实例，若健康检查发现异常，立即回滚到旧版本（蓝）。另外，设置服务降级策略，比如高峰时先处理核心交易（如申购），简化非核心功能（如减少日志记录），确保核心业务可用。这样既能快速扩容应对高峰，又能保证业务不中断。

6) 【追问清单】

• 问：如何解决新实例的冷启动问题？
  答：通过预置实例（已启动），或使用容器化（如Docker）快速启动，或提前预热（如提前加载静态资源、初始化缓存）。
• 问：如果扩容后流量下降，如何回缩资源？
  答：同样通过监控指标（如QPS低于阈值），触发自动缩容，减少实例数量，降低成本。
• 问：服务降级策略具体如何实现？
  答：通过配置路由规则（如Nginx的location匹配），高峰时拦截非核心请求，仅放行核心交易请求。
• 问：资源池的大小如何确定？
  答：根据历史峰值流量、系统资源消耗（CPU、内存）计算，通常设置比峰值高20%-50%的容量，预留余量。
• 问：是否考虑过监控延迟对扩容的影响？
  答：通过设置合理的监控延迟阈值（如5秒），避免因监控延迟导致的误判扩容。

7) 【常见坑/雷区】

• 坑1：只说扩容方法，没提业务连续性保障（如只说增加服务器，没说如何切换流量，导致服务中断）。
• 坑2：忽略服务降级策略，仅提及回滚，风险考虑不全面（如高峰时所有功能都降级，导致核心业务不可用）。
• 坑3：假设资源无限，没考虑成本，或没提缩容机制，导致资源闲置（如高峰后不回缩，长期占用资源）。
• 坑4：部署策略错误（如直接滚动升级），导致部分用户访问旧版本，部分访问新版本，出现不一致问题。
• 坑5：冷启动问题没解决，新实例启动慢，导致高峰期响应延迟，影响用户体验。