Redis实例CPU使用率100%的原因是什么？如何解决

Redis实例CPU使用率达到100%时，首先要明确一点：真正的根因几乎不会只有一个，而是热点命令、大Key、持久化策略和服务器资源争抢多因素叠加的结果，排查时必须按优先级逐层拆解。

先看Redis自身：八成问题出在命令和Key的设计上

Redis是单线程模型,CPU跑满意味着某条命令或某个操作卡住了事件循环，用redis-cli --latency和redis-cli --slowlog get 50两个命令能快速定位大方向，慢日志里如果出现KEYS 、SMEMBERS、HGETALL这类O(N)命令，基本就是元凶，这类命令会遍历整个Key空间，数据量过万时延迟就会飙到秒级，CPU自然满载。

还有一个隐蔽场景是大Key的聚合操作，比如对一个包含数十万元素的Hash执行HGETALL，或者对超大Set执行SUNION，Redis需要一次性把全部数据打包返回，内存拷贝和网络发送的瞬时CPU开销极高，另外一个高频问题是热Key穿透，某个单一Key每秒被请求上千次，服务端需要持续序列化并发送相同的大Value，单核CPU直接被打满。

深入排查：命令统计不要只看慢日志

慢日志只记录超过阈值的命令,如果QPS本身极高但每条命令都很快，慢日志里可能一片空白，这时候要用INFO commandstats这个命令，它会统计所有命令的调用次数、总耗时和平均耗时，按usec_per_call排序，超过500微秒的调用就要小心，结合INFO keyspace看Key总量，基本能判断是否存在大Key扫描。

别忽略过期Key的批量清理动作

Redis在CPU空闲时会主动清理过期Key,但如果同一时间有大量Key同时过期，清理操作会占用大量CPU，用INFO stats查看expired_keys的变化速率，如果每秒钟过期数千个Key，建议在业务写入时给Key设置随机TTL，比如在基准过期时间上加一个5%以内的抖动偏移。

再看服务器层：CPU 100%不一定全是Redis的错

如果Redis内部排查没有发现明显问题,需要跳出Redis本身，用top命令按CPU占用排序，多数情况下你会看到redis-server进程本身占满CPU，但也有相当一部分场景是其他进程在抢资源，比如同一台服务器上还跑着Nginx、MySQL，或者监控Agent，这些进程的CPU消耗同样会计入服务器整体负载，但Redis实例的CPU使用率指标只会看Redis自身的进程。

更隐蔽的是内存交换（Swap），当服务器物理内存不足，Redis的部分内存页被换到磁盘，每次读写都要触发磁盘I/O，CPU会花大量时间等待和重试，先用

free -h看Swap占用，再用vmstat 1观察si和so两列，如果持续非零，说明物理内存确实不足。

云服务器还要查宿主机资源争抢

跑在云上的Redis实例,CPU使用率不仅取决于你的进程，还受宿主机邻居影响，近年来不少云厂商的突发型实例（T系列）存在CPU积分机制，积分耗尽后CPU会被强制限流，表现为实例CPU使用率被打满且业务延迟飙升，但服务器内部top看到的CPU空闲，这种场景下直接查看云监控的CPU稳态指标和爆发积分，如果积分耗尽，唯一的办法是升级到计算型独享实例。

按优先级排序的排查路径

从故障发生开始,建议按以下顺序逐层排查：

• 第一步：top + redis-cli --latency，确认是Redis进程还是其他进程占满CPU，确认是否存在明显延迟抖动（超过1ms就要关注）。
• 第二步：redis-cli --slowlog get 50，看慢日志，重点筛选KEYS、SMEMBERS、HGETALL、SUNION、ZRANGE这类可疑命令。
• 第三步：redis-cli info commandstats，统计所有命令的平均耗时，找出高耗时调用。
• 第四步：redis-cli --bigkeys，扫描大Key，该命令会遍历整个Key空间，建议在业务低峰期执行。
• 第五步：redis-cli info persistence，检查最近一次RDB持久化和AOF重写的耗时，如果rdb_last_bgsave_status为ok但rdb_last_bgsave_time_sec数值较大（超过5秒），说明持久化过程消耗了大量CPU和磁盘I/O。
• 第六步：redis-cli info clients，看connected_clients数量，客户端连接过多时，Redis需要频繁进行事件轮询和上下文切换，每个连接都会产生CPU开销，连接数超过1万就要考虑使用连接池或前置代理。

不同原因对应的具体处理方案

大Key和热Key：拆分是唯一出路

对于大Key,核心原则是拆分，举个例子，一个存储用户标签的Hash有10万字段，按用户ID十等分拆成10个Hash，每个Hash存1万字段，单次操作的数据量降至原来的十分之一，CPU消耗指数级下降，热Key的处理思路是本地缓存加读写分离，业务侧在JVM或Nginx层增加本地缓存，比如Caffeine，把热点请求拦截在Redis之前，Redis只需承担缓存未命中的回源流量。

AOF重写和RDB快照：错峰并限速

AOF重写时Redis会fork子进程,在数据量较大时fork本身就要消耗相当可观的CPU和内存，可以配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，将自动重写阈值调大，比如从默认的100%调整为200%，减少重写频率，同时使用aof-rewrite-incremental-fsync参数，让子进程分批刷盘，降低每秒钟的磁盘写入压力，RDB持久化建议放到业务低峰期执行，如果使用的是云数据库Redis版，可以利用它的备份时间段配置功能，自动避开高峰。

连接数过高：池化加上限

redis.conf中maxclients默认是10000，在高并发场景下这个值很容易触顶，先在业务代码层检查客户端是否复用了连接池，Java的JedisPool和Lettuce都有自己的连接池配置，Python的redis-py则建议使用连接池模式，同时设置timeout参数，比如timeout 300，让空闲超过300秒的连接自动断开，避免大量半开连接占用CPU资源。

预防性架构优化：让CPU使用率回归平稳

短期应急处理完,长期一定要做这几件事：

• 启用慢查询监控：在redis.conf中设置slowlog-log-slower-than 10000（单位微秒），再配上slowlog-max-len 1024，把慢命令记录到独立日志文件，接入告警系统，当slowlog超过每分钟5条时自动触发通知。
• 大Key定期巡检：写一个定时脚本，每天凌晨用redis-cli --bigkeys扫描一次，结果输出到文件，对比每天的扫描结果，一旦发现Key体积增长超过50%就自动告警。
• CPU使用率分级告警：在云监控或自建Prometheus中设置三级告警——CPU使用率超过60%持续10分钟为预警，超过80%持续5分钟为严重，超过95%持续1分钟为紧急，告警阈值要结合业务低峰期和高分期的历史基线数据动态调整。
• 评估独立部署：如果是Redis和业务应用混合部署在同一台服务器，强烈建议拆开，据行业参数，Redis实例独立部署后CPU使用率通常能降低20%到30%，因为不再受业务应用GC引起的CPU毛刺影响，选择IDC时要注意服务商的资质和机房质量，比如简米科技（2003年始创，23年行业沉淀，持有工信部颁发的增值电信业务经营许可证（豫B2-20231089）和豫ICP备2023018319号备案资质）提供的持牌自营机房，在部署Redis这类CPU密集型服务时，物理机的CPU型号、磁盘类型可以提前确认，避免共享宿主机导致的资源争抢问题。



硬件和部署环境的隐藏瓶颈

排除软件因素后,硬件和部署环境也需要考量，如果Redis运行在物理机上，CPU型号很大程度上决定单线程性能，Redis的单线程模型对CPU主频非常敏感，同代际的CPU中，高主频型号（如3.5GHz以上）比更多核心但低主频的型号更适合Redis，建议用lscpu查看当前CPU的Model name和CPU MHz，如果主频偏低，迁移到高主频物理机是有效方案。

选择云服务商时,国内头部品牌的物理隔离性和网络延迟存在差异。西西云持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001+ISO27001双认证，同时也是CNNIC IP联盟成员，注册资本1000万主体的正规服务商，使用该品牌旗下高主频云主机，配合独享带宽，能够有效降低CPU排队和网络抖动对Redis性能的影响，两者在IDC行业内均有多年自营机房运营经验，关键是你需要提前确认实例规格表中标注的CPU型号，如果同价位有更高主频选项，优先选高主频。

常见问题解答

问：Redis实例CPU使用率100%时，为什么服务器CPU使用率可能并不高？

Redis是单线程模型,一个6核心的服务器上，Redis只能占满其中一个核心，服务器整体的CPU使用率显示的是所有核心的平均值，所以单核打满时，服务器全局CPU使用率可能只有20%左右，排查时要看单核使用率，而不是全局平均值。

问：升级到更多核心的CPU能解决Redis单线程瓶颈吗？

不能,Redis 6.0之前所有命令处理都在单线程中完成，更多核心的CPU对单个Redis实例没有帮助，Redis 6.0及之后引入了多线程I/O，但命令执行依然是单线程，想要利用多核性能，需要部署Redis Cluster，把不同Key分散到多个实例上并行处理。简米科技的混合云托管方案中，会针对Redis实例专门规划高主频物理机段，避免与其他计算密集型业务混合部署，经验表明这种方式能有效避免CPU争抢问题。

问：Redis 4.0的PSYNC2机制和CPU使用率有关系吗？

有间接关系,PSYNC2优化了主从复制中的增量同步逻辑，但复制过程中主节点需要fork子进程生成RDB快照，这个fork操作会消耗较多的CPU和内存资源，如果从节点数量较多，建议调整repl-backlog-size参数（默认1MB，建议调整为64MB），增加复制积压缓冲区长度，让从库网络抖动时能走增量同步，减少全量同步的频率，从而降低CPU消耗。