支撑百万级 QPS 的系统优化和故障处理经验总结

百万 QPS 背后不是“某个技术”，而是一整套架构优化体系 + 全链路容错机制 + 实战故障应对经验的积累。

一、架构设计优化（抗高并发的基石）

1. 微服务拆分 & 异步化
   ● 拆分高频调用模块，做到职责单一、独立扩展
   ● 大量使用 异步消息队列（如 Kafka、RocketMQ） 进行削峰填谷
2. 多级缓存架构
   ● 一级缓存：本地缓存（Guava、Caffeine）加速热点数据访问
   ● 二级缓存：Redis 集群 支撑大量读请求，必要时启用热key隔离
   ● 三级缓存：数据库/ES，根据一致性需求灵活选择
3. 限流 & 熔断
   ● 使用令牌桶、漏桶算法（如 Sentinel、Hystrix）保护核心接口
   ● 高并发入口必须限流，防止雪崩式调用链放大

二、底层性能优化

1. JVM & GC 调优
   ● 设置合理的 堆大小、GC 策略（如 G1、ZGC）
   ● 使用 GC 日志分析工具（GCViewer、jstat） 观察 Full GC 次数和 STW 时间
   ● 预热期间完成 class load，减少线上惰性初始化开销
2. IO 优化
   ● Netty/epoll + 多 Reactor 模型 替代传统阻塞式 IO
   ● 使用 对象池、连接池 避免频繁创建/销毁资源（如数据库连接池 HikariCP）
3. 数据结构 & 算法
   ● 业务热路径中，使用更轻量的数据结构（如数组代替 List、位图代替 Set）
   ● 常见优化如：布隆过滤器 降低无效请求穿透数据库

三、数据库与中间件层优化

1. 数据库层
   ● 分库分表：基于用户 ID / 订单号等哈希分片
   ● 读写分离：主写从读，配合延迟监控与读一致性策略
   ● SQL 优化：只查必要字段，避免 SELECT *
2. Redis 优化
   ● 使用 Pipeline 批量操作 降低 RTT
   ● 关注 热点 key 问题（可用预热、分片、随机后缀、local cache 等）
   ● Redis 异常（阻塞/延迟）必须快速降级或 fallback
3. MQ 优化
   ● Kafka 场景下：提前设定合理的分区数 + 并发消费者 + ack 策略
   ● 遇到消息堆积，要具备：报警 + 队列积压指标 + 自动扩容能力

四、故障处理策略（实战经验）

1. 实时监控 & 异常预警
   ● 接入 Prometheus + Grafana / Skywalking / Linkerd / 阿里ARMS
   ● 核心维度：RT、QPS、异常率、GC 次数、线程池耗尽等
   ● 典型报警：线程池 queue full、Full GC 频繁、Redis RTT 激增、MQ lag 异常
2. 快速隔离与降级
   ● 发现某模块异常响应慢：
   ○ 快速从负载中摘除实例
   ○ 使用熔断器强制短路、fallback 静态数据
   ● 核心路径启用 降级 mock / 降级缓存 / 兜底服务
3. 典型事故处理经验
   ● Redis 延迟升高 → 使用 localCache 兜底 + 自动重试降级
   ● 数据库主从延迟 → 检测 binlog 落后量，大流量时临时禁止读从库
   ● MQ 堆积严重 → 扩容 consumer 数量 + 优先消费高优先级队列

五、实战案例（示例）

某活动秒杀系统，支撑 120 万 QPS 峰值：
● 请求层 Nginx + Netty 接入层，使用 Lua 脚本预限流
● 请求进入后，先查本地缓存，无命中则查 Redis + 异步预热
● 秒杀结果写入 MQ 异步落库，数据库层禁用事务，批量插入
● 所有操作环节监控可视化，RT/错误率超限自动报警
● 事故演练：模拟 Redis 延迟、DB 拒绝、MQ 消息堆积处理流程