当前位置：首页 > 问答 > 正文

Redis阻塞问题怎么查？深度剖析那些专家们常用又实操的方法技巧

太叔访天
问答
2026-01-04 03:52:09
11

关于Redis阻塞问题怎么查，网上有很多技术文章，比如阿里云开发者社区的一篇文章《Redis延迟问题排查》就讲得很详细（引用来源：阿里云开发者社区），这篇文章以及许多专家的实践都指出，排查Redis阻塞不能瞎猜，得有一套清晰的思路和方法,下面我就把这些实操性强的方法技巧给你捋一捋。

第一步：你得先知道Redis“慢”了

你不能等到业务彻底瘫痪了才发现问题,专家们通常会借助一些工具来主动发现或快速确认阻塞。

看监控大盘： 这是最基本也是最重要的一步，现在公司一般都用云服务或者自建了监控系统（如Prometheus+Grafana）,你要重点关注几个核心指标：
- 延迟（Latency）： 看看命令的平均响应时间、最大响应时间是不是突然变高了，一个平时1毫秒就能响应的命令，突然变成了100毫秒,那肯定有问题。
- QPS（每秒查询数）： 看看流量有没有异常暴增，有时候不是Redis本身的问题，而是访问量太大，把它“打趴”了。
- 连接数： 看看客户端连接数是不是异常的多，可能是连接没有正确关闭,把Redis的资源耗尽了。
- 内存使用率： 看看内存是不是快满了，内存满了会触发淘汰策略，甚至导致写操作失败,也可能变慢。
- CPU使用率： 看看CPU是不是一直处于高负荷状态。
使用Redis自带命令：redis-cli --latency （引用来源：Redis官方文档），这个命令是个非常实用的实时检测工具，你可以在服务器上直接运行 redis-cli --latency -h，它会持续监测并显示延迟情况，如果延迟值（单位毫秒）一直很高或者有规律的毛刺,那就说明存在阻塞问题。

第二步：定位是哪个“坏蛋”命令导致的阻塞

知道Redis慢了之后，下一步就是要揪出“元凶”——到底是哪个命令执行得太慢了。

使用慢查询日志（Slow Log）： 这是Redis提供的杀手锏功能（引用来源：Redis官方文档），Redis会把执行时间超过预设阈值（由 slowlog-log-slower-than 配置，单位微秒，默认10000微秒即10毫秒）的命令记录下来，你可以通过命令 SLOWLOG GET 来查看最近的慢查询,从日志里你能清晰地看到：
- 是哪个具体的命令（HGETALL一个大Key）。
- 这个命令执行了多久。
- 命令执行的具体时间点。
- 当时是哪个客户端发起的。这基本上能解决一大半的阻塞定位问题。
使用redis-cli的额外功能：redis-cli --latency-history 和 --intrinsic-latency （引用来源：Redis官方文档）。
- --latency-history：和之前的 --latency 类似，但它会每隔一段时间（默认15秒）重置统计，这样你就能看到延迟是不是周期性出现的,有助于判断是不是定时任务导致的。
- --intrinsic-latency：这个命令很关键，它用于测试Redis服务所在服务器的“固有延迟”，你需要在服务器负载较低时运行它（redis-cli --intrinsic-latency 100，监测100秒），它会告诉你抛开网络和Redis命令本身，这台服务器的基线延迟是多少，如果这个固有延迟就很高，那问题可能出在服务器硬件、虚拟化环境或操作系统上,而不是Redis进程内部。

第三步：深入分析常见的阻塞“病根”

通过上面的手段定位到大致方向后,就要针对几种常见病因进行深入检查了。

检查“大Key”（Big Key）： 这是最常见的阻塞原因之一，所谓大Key，是指一个Key对应的Value非常大，比如一个Hash里有百万个字段，或者一个String值有几十MB，操作这种Key（比如删除它、查询它）会严重消耗CPU，并长时间阻塞Redis的单线程，你可以用 redis-cli --bigkeys 命令来扫描整个数据库，找出可能的大Key（引用来源：Redis官方文档及众多实践案例），找到后,解决方案通常是对大Key进行拆分。
检查“热Key”（Hot Key）： 某个Key被超高并发地访问，虽然它本身不大，但巨大的流量会集中在一个Redis实例的一个点上，造成服务器CPU压力激增，形成瓶颈,这个通常需要靠监控或通过代码分析来发现。
检查持久化操作（RDB和AOF）： Redis为了数据安全，需要把内存数据写到硬盘上,这个操作叫持久化。
- 生成RDB快照（bgsave）： 虽然叫bgsave（后台保存），但创建子进程的瞬间会阻塞父进程，如果数据量巨大，fork操作本身就可能非常耗时,导致服务短暂停顿。
- AOF重写（bgrewriteaof）： 类似bgsave,也会fork子进程。
- AOF的写回策略： 如果设置为 appendfsync always，表示每个写命令都同步刷盘，这样最安全，但性能最差，每次写操作都可能因磁盘IO而延迟，通常建议设为 everysec（每秒刷一次）。
检查操作系统交换区（Swap）： 如果服务器物理内存不足，操作系统会把内存中不常用的数据换到硬盘上的交换区（Swap），一旦Redis的数据被换出，下次访问时就需要从极慢的硬盘读回来，这会造成灾难性的延迟，你可以用 redis-cli info | grep used_memory 查看Redis用了多少内存，再用 free -m 命令查看系统内存和Swap使用情况，如果Swap被使用了,那就要警惕了。
检查网络问题： 网络不稳定、带宽打满、连接数过多等也会导致客户端感知到的延迟，可以用 ping 命令看网络是否通畅，用 iftop 等工具看带宽使用情况。