Redis 实例 CPU 飙高到 90%，如何排查和解决？

Redis CPU飙升至90%的排查与解决，核心是先定位“高CPU命令/来源”，再针对性优化命令、配置或架构，按“定位-分析-解决”三步执行。

一、第一步：快速定位CPU高负载来源（核心）

CPU高本质是“命令执行开销过大”或“并发压力过高”，优先用Redis内置命令和系统工具锁定根因。

1. 定位高消耗命令（最直接）

通过redis-cli查看命令执行情况，锁定耗时/高频命令：

• 查看实时命令吞吐量：

  执行 redis-cli -h [IP] -p [端口] info stats，重点看 instantaneous_ops_per_sec（每秒命令数，正常几百~几万，过高会压垮CPU）。

• 查看慢命令（关键）：

  执行 redis-cli -h [IP] -p [端口] slowlog get 20（查看最近20条慢命令，默认阈值10ms，可临时调小：config set slowlog-log-slower-than 5000，即5ms以上记录）。
  常见高CPU慢命令：KEYS *（全量遍历，O(n)）、HGETALL（全量取哈希，O(n)）、SINTER（集合交集，O(n)）、ZUNIONSTORE（有序集合合并，O(n)）。

• 查看客户端连接与命令：

  执行 redis-cli -h [IP] -p [端口] client list，按cmd列筛选执行频繁命令的客户端（如大量HGETALL），按addr定位来源服务。

2. 系统级定位（确认是否Redis本身导致）

• 执行 top 命令，观察redis-server进程的CPU占比，排除其他进程抢占（如java、nginx等）。

• 若需细粒度分析（如Redis内部函数）：执行 perf top -p [Redis进程ID]，查看函数CPU占比（如dictFind对应哈希查找、zslInsert对应有序集合插入，占比过高则对应相关命令频繁）。

二、第二步：分析高CPU的核心原因（按优先级排序）

原因1：执行“高复杂度命令”（最常见）

• 特征：slowlog中大量O(n)、O(n²)命令，单条命令执行耗时超10ms，且调用频繁。

• 例子：用KEYS *遍历全库（数据量10万+时CPU直接飙升）、HGETALL user:123（哈希表有1万+字段时全量读取）。

原因2：并发压力过高（QPS突增）

• 特征：instantaneous_ops_per_sec远超Redis承载上限（单实例一般建议QPS≤10万），且多为简单命令（如GET、SET）。

• 例子：秒杀活动、缓存穿透导致大量请求直接打Redis，简单命令高频执行累积CPU开销。

原因3：数据结构不合理/使用不当

• 特征：用错数据结构导致命令开销变大，如：

  用List实现队列时，频繁LPOP/RPOP（可改用Redis Stream）；

  用String存储JSON大对象（10KB+），频繁GET/SET（可拆分为Hash）。

原因4：Redis配置不合理

• 特征：未开启关键优化，如：

  未开启IO多路复用（默认开启，但旧版本可能配置错误，如redis.conf中io-threads 1未调整）；

  开启了“持久化阻塞”（如RDB快照时数据量过大，fork耗时过长；AOF刷盘策略为always，频繁磁盘IO占用CPU）。

三、第三步：针对性解决（按原因对应方案）

方案1：优化“高复杂度命令”（立竿见影）

• 替代全量遍历命令：

• KEYS * → 改用 SCAN 0 MATCH * COUNT 100（分批遍历，无阻塞）；

• HGETALL key → 改用 HMGET key field1 field2（按需取字段）或 HSCAN（分批取哈希字段）；

• SINTER set1 set2 → 改用 SISMEMBER 循环判断（小集合场景），或业务层预计算结果存入Redis。

• 禁止低频高耗命令：通过redis.conf配置 rename-command KEYS “”，直接禁用危险命令。

方案2：降低并发压力（扛住高QPS）

• 扩容分担压力：

  主从复制：主库写，从库读（如3个从库分担查询QPS）；

  分片集群：用Redis Cluster将数据按槽位拆分到多个实例（如8个实例，每个实例QPS降至1/8）。

• 缓解缓存穿透/击穿：

• 穿透：不存在的key缓存空值（过期时间30秒），或用布隆过滤器拦截；

• 击穿：热点key用SET key value NX EX 3600加互斥锁，避免并发重建缓存。

方案3：优化数据结构与使用方式

• 拆分大对象：

  大JSON（10KB+）→ 拆分为Hash（如user:123:name、user:123:age 改为 HSET user:123 name “xxx” age 20）；

  大列表（10万+元素）→ 拆分为多个小列表（如list:1、list:2），按范围访问。

• 选对数据结构：

  消息队列 → 用Stream（支持ACK、分组消费）替代List；

  排行榜 → 用Sorted Set（ZADD/ZRANGE），避免自己维护排序。

方案4：调整Redis配置（减少CPU浪费）

• 优化IO线程：redis.conf中设置 io-threads 4（线程数≈CPU核心数的1/2，仅Redis 6.0+支持，提升网络IO效率）。

• 优化持久化：

  RDB：避开业务高峰执行（如save 3600 1，1小时内改1次才快照），或用bgsave替代save（后台执行，不阻塞主线程）；

  AOF：刷盘策略改为 appendfsync everysec（每秒刷盘，平衡性能与安全性，避免always的高频IO）。

• 关闭无用功能：如关闭cluster-enabled（非集群场景）、lazyfree-lazy-eviction yes（惰性删除过期key，减少阻塞）。

四、应急处理（CPU过高时先止血）

若CPU已达90%+，先临时降低负载，再排查优化：

1.暂停非核心业务的Redis请求（如运营报表查询）；2.重启Redis（临时释放资源，需确保数据已持久化，避免丢失）；3.切换从库为主库（若主库CPU过高，先让从库承接流量）。

总结

Redis CPU高的核心是“命令开销”和“并发压力”，排查时先抓“慢命令”和“高频命令”，解决时优先优化命令和数据结构，再通过扩容、配置调整根治，最终结合监控（如Prometheus+Grafana）长期观察命令执行和CPU趋势，避免复发。