Redis性能挖掘里头CPU瓶颈到底咋查，深度剖析redis查找cpu问题

要搞清楚Redis的CPU瓶颈到底在哪,不能光盯着CPU使用率100%这个结果看，得像个侦探一样，一层一层地剥开线索，找到真正的“元凶”，下面就是一步步的排查方法。

第一招：先看宏观，再看微观——操作系统工具是第一步

当发现Redis服务器整体CPU使用率很高时,第一步不是直接登录Redis，而是先用操作系统的命令看大局，最常用的就是top命令。

打开终端,输入top，然后按1键，你会看到每个CPU核心的使用情况，这里很关键：如果Redis是单线程模型（处理命令的主线程），一个健康的Redis应该主要只把一个CPU核心跑满，其他核心相对空闲，如果你发现多个核心的使用率都很高，那问题可能不在Redis本身，而是操作系统层面有其他进程在消耗CPU，或者服务器正在经历其他高负载任务，这时候你需要看top列表里，除了redis-server这个进程，还有哪些进程占用了大量CPU，这步是排除法，避免误判。

如果确认就是redis-server进程吃光了某一个或两个核心的CPU，那我们就要深入Redis内部了。

第二招：Redis自带的“体检报告”——INFO命令

Redis自己提供了一个非常强大的诊断工具,就是INFO命令，在Redis命令行里执行INFO commandstats，它会返回一个黄金般的列表。

这个列表统计了Redis执行过的所有命令的次数和总耗时,你会看到类似这样的行：cmdstat_get:calls=1000000,usec=5000000,usec_per_call=5.00，这里calls是调用次数，usec是总耗时（微秒），usec_per_call是每次调用的平均耗时。

排查关键点就在这里：

1. 看命令类型：是不是有大量的KEYS *、HGETALL这种复杂度很高的命令？KEYS *命令会遍历所有键，数据量一大直接卡死，这种命令绝对要避免在生产环境使用。
2. 看平均耗时：即使是一些O(1)复杂度的命令，比如GET、SET，如果它的usec_per_call异常的高，比如平时都是零点几毫秒，现在变成了几毫秒甚至几十毫秒，这说明Redis主线程可能被其他事情阻塞了，导致它不能及时处理简单的命令。
3. 看大键操作：如果你发现cmdstat_hgetall的调用次数不多，但总耗时usec却非常高，这很可能意味着你在操作一个非常大的Hash键，一次性获取一个包含几万字段的Hash，即使复杂度是O(N)，这个N太大也会导致CPU长时间运算。

第三招：揪出“慢查询”——那些拖后腿的操作

INFO commandstats是总量统计，但有时候是某个特定的、执行很慢的命令间歇性拉高了CPU，这时候就要用Redis的慢查询日志。

Redis可以设置一个阈值,比如10毫秒，任何执行时间超过10毫秒的命令都会被记录下来，你需要检查Redis配置文件redis.conf里的slowlog-log-slower-than参数（或者用CONFIG GET命令查看），并确保慢日志是开启的。

然后使用SLOWLOG GET [数量]命令，比如SLOWLOG GET 10，来获取最近10条慢查询，这里会清晰地告诉你：是哪个命令慢了、执行时传入的参数是什么、具体花了多长时间，这能直接帮你定位到是哪个业务代码在发送危险的命令，或者是在操作哪些巨大的数据键。

第四招：警惕“隐形杀手”——持久化带来的CPU压力

Redis的CPU高,不一定全是处理客户端命令导致的，它的持久化机制（RDB快照和AOF日志）在后台工作时，也会消耗大量CPU资源。

• RDB持久化：当执行BGSAVE生成快照时，Redis会fork一个子进程，在数据量非常大的情况下，fork操作本身可能会因为复制父进程的内存页表而短暂阻塞主线程（尤其在虚拟机环境下），并且子进程生成RDB文件是一个密集的CPU和磁盘IO操作。
• AOF持久化：如果设置了appendfsync always（每次写命令都刷盘），这会极大增加IO压力，间接影响CPU，如果AOF文件过大，触发了AOF重写，这和BGSAVE一样，也会fork子进程并进行密集的CPU操作。

排查的时候,需要确认高CPU时段是否正好与RDB快照的定时任务或者AOF重写时间点重合，可以通过查看Redis的日志文件，或者用INFO persistence命令来观察last_bgsave_status和aof_rewrite_in_progress等字段的状态。

第五招：终极武器——性能剖析工具

如果以上方法都用了,还是没找到明显的问题，比如没有慢查询，命令也都很简单，但CPU就是高，这时候可能需要使用更底层的性能剖析工具，比如perf。

通过在系统层面运行perf top -p <redis_pid>命令，你可以实时看到Redis进程内部，CPU时间主要花费在哪些函数调用上，这需要一些编译和系统的知识，但它能告诉你最精确的答案——CPU周期到底用在了内存分配、网络读写、还是核心数据结构的操作上，不过这个方法相对专业，通常是最后的手段。

总结一下排查路径： 先top看是不是Redis的锅 -> 再用INFO commandstats看命令的总体开销 -> 然后用SLOWLOG抓取具体的慢操作 -> 同时检查持久化（RDB/AOF）是否在捣乱 -> 最后考虑使用perf这样的底层工具进行深度剖析，按照这个顺序，绝大多数Redis的CPU瓶颈问题都能水落石出。

参考资料：本回答的方法论综合自Redis官方文档中关于INFO命令、慢查询日志、持久化的说明，以及业界常见的Redis性能优化实践，如排查大键、避免危险命令等。