redis的qps从100飙升到10000的全流程解决方案

Redis QPS 从 100 飙升至 10000 属于典型的流量突增场景，核心排查逻辑是先区分 "合法流量增长" 还是 "异常 / 低效请求导致"，再针对性止血 + 根因修复，全程需结合 Redis 监控、日志和命令分析，以下是全流程排查与解决方案：

一、紧急止血：避免 Redis 宕机（0-5 分钟）

Redis 单实例 QPS 极限约 10 万 - 15 万，但突增到 1 万可能导致 CPU / 内存 / 网络打满，先快速控风险：

临时限流 / 降级
- 若 Redis 接入了网关 / 代理（如 Nginx、Kong、Redis Cluster Proxy），立即配置 Redis QPS 限流阈值（如设为 12000，留缓冲），超出请求返回 "服务繁忙" 或走降级逻辑（如返回本地缓存）。
- 对非核心业务的 Redis 请求（如统计、日志上报）直接降级，暂停调用，优先保障核心流程（如下单、支付）。
扩容缓解压力
- 若为单机 Redis，快速切换至 Redis Cluster 并新增节点（如从 3 节点扩至 6 节点），分摊流量；若已为集群，将热点槽位迁移至空闲节点。
- 检查 Redis 所在服务器的资源（CPU、内存、网卡），若 CPU>90%/ 网卡带宽打满，临时扩容服务器配置（如 CPU 核数翻倍、带宽升级）。
禁用危险命令
- 临时禁用高开销命令（如KEYS *、FLUSHDB、HGETALL、SMEMBERS），避免雪上加霜（可通过redis.conf或CONFIG SET disable-commands "KEYS,FLUSHDB"配置）。

二、定位根因：明确 QPS 飙升的核心原因（5-30 分钟）

通过 Redis 自带工具 + 监控平台，从 "请求来源、命令类型、业务场景" 三维度分析：

步骤 1：基础监控分析（先看宏观指标）

通过redis-cli info stats/ 监控平台（如 Prometheus+Grafana、Redis Insight、阿里云 Redis 控制台）查看核心指标：

核心指标	异常表现	指向问题
`instantaneous_ops_per_sec`	稳定 100→突增 10000	流量真实增长 / 低效请求叠加
`used_cpu_sys`/`used_cpu_user`	CPU>80%	计算密集型命令（如排序、聚合）或高频小命令（如 INCR）
`used_memory`/`used_memory_rss`	内存突增	大 value 写入、缓存过期策略失效
`network_input_bytes`/`network_output_bytes`	网卡打满	大流量请求（如 HGETALL、大字符串 GET）
`keyspace_hits`/`keyspace_misses`	缓存命中率骤降（<80%）	缓存穿透 / 缓存失效，导致大量无效请求

步骤 2：分析请求来源（找流量入口）

定位调用方 IP / 服务：
- 查看 Redis 慢日志 / 访问日志（需提前开启slowlog），执行slowlog get 100，筛选请求来源 IP；
- 若接入了链路追踪（如 SkyWalking、Pinpoint），直接查看调用 Redis 的服务列表，确认是否某服务 / IP 的调用量突增（如某新上线功能、定时任务）。
判断流量合法性：
- 若单 IP 调用量占比 > 50%，大概率是爬虫、恶意攻击或客户端 BUG（如无限重试、循环请求），直接在防火墙 / Redis 端拉黑该 IP；
- 若调用方为内部服务，检查是否有代码 BUG（如重试逻辑异常、循环查询 Redis）。

步骤 3：分析命令类型（找低效 / 高频命令）

执行redis-cli --stat（实时统计命令执行次数）或info commandstats（按命令统计），重点关注：

高频小命令：
- 如INCR/DECR/HSET/GET/SET占比 > 90%，且 QPS=10000，可能是正常业务增长（如秒杀、计数场景），或客户端无缓存直接调用 Redis；
高开销命令：
- 若SORT/ZUNIONSTORE/HGETALL/SMEMBERS/KEYS占比高，哪怕单次调用，也会因耗时久导致 QPS "被动升高"（请求堆积）；
- 若MGET/MSET调用少，但单条命令携带上千个 key，等价于放大了 QPS（如 1 次 MGET 带 1000 个 key=1000 次 GET）；
无效请求：
- 缓存穿透：GET不存在的 key 占比高（keyspace_misses高），导致 Redis 空查，QPS 虚高；
- 缓存雪崩：大量 key 同时过期，导致所有请求直接打 Redis，QPS 突增；
- 缓存击穿：单个热点 key 过期，大量请求同时访问该 key，瞬间拉高 QPS。

三、分场景解决方案（30 分钟后）

根据根因针对性修复，从 "临时缓解" 到 "长期优化"：

飙升类型	临时解决方案	长期优化方案
正常业务增长（如秒杀）	1. 扩容 Redis Cluster 节点数；2. 热点 key 分片（如将 count:123 拆为 count:123:1~10）；3. 增加本地缓存（如 Guava）分担流量	1. 配置 Redis 弹性伸缩（QPS 超 8000 自动扩容）；2. 对计数类场景使用 Redis HyperLogLog / 计数器组件；3. 压测验证 Redis 极限 QPS（如模拟 2 万 QPS）
高频低效命令（如 HGETALL、KEYS）	1. 临时替换为低开销命令（如 HGETALL→HSCAN 分批获取，KEYS→SCAN）；2. 限制大 key（>100KB）的读写	1. 规范 Redis 命令使用手册，禁用高开销命令；2. 拆分大 key（如大 Hash 拆为多个小 Hash）；3. 对聚合类查询（如排序）迁移至离线计算（如 Spark）
缓存穿透	1. 临时配置空值缓存（如对不存在的 key 设置过期时间 1 分钟）；2. 布隆过滤器拦截无效 key	1. 接入全局布隆过滤器（如 RedisBloom 模块）；2. 业务层校验请求参数，过滤无效 key
缓存雪崩	1. 临时延长过期 key 的 TTL；2. 对过期时间添加随机值（如 TTL=30 分钟 ±5 分钟）	1. 核心 key 设置永不过期，通过后台异步更新；2. 分级缓存（本地缓存 + Redis）；3. 过期时间错开（按业务维度分批过期）
缓存击穿	1. 临时对热点 key 加互斥锁（如 SETNX），只允许 1 个请求更新缓存，其余等待；2. 热点 key 设为永不过期	1. 接入 Redis 热点 key 探测工具（如 Redis Cluster 的 hot-key-detect）；2. 热点 key 预加载 + 本地缓存；3. 使用 Redisson 分布式锁优化缓存更新逻辑
恶意攻击 / 客户端 BUG	1. 拉黑异常 IP / 服务；2. 限制单客户端连接数（CONFIG SET maxclients 1000）；3. 通知调用方修复重试逻辑	1. Redis 接入 WAF，拦截高频异常请求；2. 客户端添加请求限流（如每秒调用 Redis 不超过 100 次）；3. 完善客户端重试机制（最多 3 次，间隔 100ms）
大流量请求（网卡打满）	1. 临时压缩 Redis 传输数据（如使用 Protocol Buffer 代替 JSON）；2. 限制单条请求的 value 大小（<10KB）	1. 开启 Redis 压缩（CONFIG SET rdbcompression yes）；2. 大文件 / 大数据迁移至对象存储（如 OSS），Redis 仅存索引

四、复盘与长效防护（问题解决后 1-2 天）

完善监控告警：
- 新增告警规则：QPS 5 分钟内增长超 200%、CPU>80%、缓存命中率 < 90%、大 key 数量突增；
- 监控维度：QPS、CPU、内存、网卡、缓存命中率、慢命令数、大 key 数量。
规范 Redis 使用：
- 制定 Redis 开发规范：禁用高开销命令、限制 key/value 大小、强制设置过期时间（核心 key 除外）；
- 上线前审核：所有 Redis 调用需经过代码评审，避免低效 / 高频请求。
应急演练：
- 模拟 Redis QPS 突增到 1 万、2 万的场景，验证限流、扩容、降级方案的有效性；
- 整理 Redis 应急排查手册，明确责任人、工具（如 slowlog、info 命令）和步骤。

关键工具速查

排查目标	核心命令 / 工具
实时 QPS / 命令统计	`redis-cli --stat`、`info commandstats`
慢请求分析	`slowlog get 100`、`slowlog len`
大 key 检测	`redis-cli --bigkeys`、Redis Insight
流量来源	Redis 访问日志、链路追踪平台（SkyWalking）
资源监控	`top`（CPU / 内存）、`iftop`（网卡）、Prometheus+Grafana