以下是应对业务量突然提升100倍QPS的系统性解决方案，分为 紧急止血、快速扩容、架构优化、容灾兜底 四个阶段，附带具体操作指令和示例：

---

一、紧急止血（5分钟内）

1. 全局监控仪表盘

# 实时监控核心指标（示例）
watch -n 1 "echo 'CPU: ' $(top -bn1 | grep Cpu | awk '{print $2}')%; \
echo 'MEM: ' $(free -m | awk '/Mem/{print $3}')MB; \
echo 'DISK: ' $(iostat -x | awk '/sda/{print $NF}')%util; \
echo 'QPS: ' $(cat access.log | wc -l)"

关键阈值：

• CPU > 80% → 触发扩容
• 磁盘I/O等待 > 50ms → 检查慢查询
• 503错误率 > 1% → 启动限流

2. 限流熔断

Nginx层限流（全局限流）：

# 限制单个IP每秒100请求（burst允许突发200）
limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=100r/s;
limit_req zone=ip_limit burst=200 nodelay;

代码层熔断（Hystrix配置）：

@HystrixCommand(
  fallbackMethod = "fallbackMethod",
  commandProperties = {
    @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds", value="500"),
    @HystrixProperty(name="circuitBreaker.errorThresholdPercentage", value="50") // 错误率超50%触发熔断
  }
)

3. 降级非核心功能

• 关闭实时统计、日志记录等辅助功能
• 静态化动态页面（如商品详情页静态缓存）

---

二、快速扩容（30分钟内）

1. 计算扩容倍数

扩容公式：

目标机器数 = 当前机器数 × (目标QPS / 当前QPS) × 冗余系数（1.5~2）
示例：当前10台机器支撑1万QPS → 100万QPS需10×100×1.5=1500台（需验证）

2. 云资源快速扩容

K8s自动扩缩容：

# 设置CPU阈值触发自动扩容（示例）
kubectl autoscale deployment my-api --cpu-percent=70 --min=10 --max=1000

CDN预热：

# 提前缓存热门资源（如商品图片）
curl -X POST "https://api.cdn.com/prefetch" -d '{"urls":["/img/123.jpg","/css/main.css"]}'

3. 数据库临时扩容

读写分离：

-- 主库开启binlog
SHOW MASTER STATUS;
-- 从库配置
CHANGE MASTER TO MASTER_HOST='master_ip', MASTER_USER='repl', MASTER_PASSWORD='pass';
START SLAVE;

连接池调优：

# HikariCP配置（示例）
spring.datasource.hikari:
  maximum-pool-size: 200  # 默认10
  connection-timeout: 3000
  leak-detection-threshold: 5000

---

三、架构优化（1-3天）

1. 缓存雪崩防护

// 本地缓存+Redis多级缓存（示例）
LoadingCache<String, Object> localCache = CacheBuilder.newBuilder()
    .maximumSize(1000)
    .expireAfterWrite(30, TimeUnit.SECONDS)
    .build(key -> redis.get(key)); 

// Redis集群分片
JedisCluster jedis = new JedisCluster(new HostAndPort("redis-cluster", 6379));

2. 异步化改造

MQ削峰填谷（RocketMQ示例）：

// 订单创建异步化
public void createOrder(Order order) {
    rocketMQTemplate.asyncSend("order_topic", order, new SendCallback() {
        @Override
        public void onSuccess(SendResult sendResult) {
            // 记录发送成功
        }
        @Override
        public void onException(Throwable e) {
            // 补偿重试
        }
    });
}

3. 数据库分库分表

ShardingSphere分片策略：

# 按user_id分64库+分16表
sharding:
  tables:
    order:
      actualDataNodes: ds${0..63}.order_${0..15}
      databaseStrategy:
        standard:
          shardingColumn: user_id
          shardingAlgorithmName: mod64
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: mod16

---

四、容灾兜底（持续迭代）

1. 混沌工程演练

# 模拟网络延迟（随机延迟50-200ms）
tc qdisc add dev eth0 root netem delay 50ms 200ms 25%
# 模拟节点宕机
kubectl drain node-01 --ignore-daemonsets --delete-emptydir-data

2. 全链路压测

压测脚本示例（JMeter）：

<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="100万QPS压测">
  <intProp name="ThreadGroup.num_threads">1000</intProp>
  <stringProp name="ThreadGroup.duration">600</stringProp>
</ThreadGroup>

3. 多活容灾

跨云多活架构：

# DNS智能解析（示例权重分配）
www IN A 100.1.1.1   # 主云权重80
www IN A 200.2.2.2   # 备云权重20

---

关键流程图解

流量突增
│
├─ 紧急阶段（0~5分钟）  
│   ├─ 限流熔断（Nginx/Hystrix）  
│   ├─ 降级非核心服务  
│   └─ 监控报警（CPU/QPS/错误率）  
│
├─ 扩容阶段（5~30分钟）  
│   ├─ 横向扩展（K8s AutoScaling）  
│   ├─ 数据库读写分离  
│   └─ CDN预热  
│
├─ 优化阶段（1~3天）  
│   ├─ 缓存多级化（本地+Redis）  
│   ├─ MQ异步削峰  
│   └─ 分库分表（ShardingSphere）  
│
└─ 容灾阶段（持续）  
    ├─ 混沌工程（故障注入）  
    ├─ 全链路压测  
    └─ 多活部署（跨云容灾）

通过以上策略，可在不同阶段有效应对流量冲击，建议结合实际业务场景选择优化优先级。最终需通过常态化压测验证系统极限承载能力。