Redis超时、阻塞问题的排查思路

Redis 自身问题

1、持久化带来的阻塞问题（AOF 重写和生成 RDB）

Redis 在做 AOF 重写或者生成 RDB 的时候，需要 fork 操作创建子进程，fork 的过程，虽然不会直接拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。

从经验上来讲，如果你的 Redis 有 10GB 的数据，那么会需要复制大概 20MB 的内存页表，正常情况下，fork 耗时是每 个GB 消耗 20ms 的时间。如果在一个 QPS 是 5w 的 Redis 中，fork 消耗 1s，则拖慢大概 5w 的请求。这是非常严重的问题。

2、CPU 使用饱和

如果把一个 Redis 的 CPU 跑到将近 100%，这是非常危险的，判断 CPU 是否占用过高，我们可以简单使用下面 2 个方法：

1. top 命令查看，这个最直接。

2. redis-cli --stat 命令，查看当前 Redis 每秒钟处理的命令个数，如果接近 8~10w，说明当前 Redis 的压力特别大（这个判断不一定准确，如果你使用了高算法复杂度的命令，可能很小的 QPS Redis 就扛不住了）。

3、慢查询

如果我们对整个 Redis 执行了 keys * 或者对一个大的 hash 结构执行了 hgetall 等命令，那么这个命令必然执行很慢。因为它的复杂度是 O(n)。

当我们执行 Redis 命令的时候，如果超过我们设定的慢查询阈值，就会被记录在 Redis 的慢查询里面，Redis 的慢查询可以使用 slowlog get n 来查找。

注意：Redis 的慢查询记录的是命令执行时间，而不包括数据网络传输时间和命令排队时间。常见的一个误区就是客户端阻塞之后，业务同学总觉得 Redis 慢，但是很有可能是在等待其他命令执行。

4、大 key

大 key 的读取和写入需要更大的内存空间，因此很容易造成阻塞，通常情况下，我们可以使用 redis 自带的 redis-cli --bigkeys 命令来找到每个数据类型的大 key，并进行处理。

外在问题

1、CPU 竞争或者多 CPU NUMA 架构的跨内存访问

如果 Redis 所在的服务器有多个核心，部署了多个 Redis 实例，实例之间往往存在 CPU 竞争以及 CPU 的上下文切换，而这种竞争和上下文切换会降低 Redis 的性能。

这个时候，我们往往会通过绑定 CPU 核心的方法来减少 CPU 之间的竞争问题，这个处理方式正常情况下没有问题。但是当我们将 Redis 的持久化开启，Redis 做 bgsave 或者 AOF 重写的时候，父子进程将产生 CPU 竞争，影响 Redis 稳定性。因此，在开启了持久化的 Redis 上，不建议绑定核心，而是应该去调整 Redis 的部署架构。

再说 NUMA 访问，如果在 CPU 多核场景下，Redis 实例被频繁调度到不同 CPU 核上运行的话，那么就会出现内存的远端访问，远端访问的过程中，对 Redis 实例的请求处理时间影响就更大了。每调度一次，一些请求就会受到运行时信息、指令和数据重新加载过程的影响，这就会导致某些请求的延迟明显高于其他请求。

2、使用了 SWAP 内存交换

如果操作系统的内存不够，将一部分内存数据换出到磁盘，那么 Redis 的访问无疑会受到影响，因为内存和磁盘的访问速度，差了好几个数量级。因此，使用 Redis 的机器上，尽量关闭 swap，并设置 Redis 的 maxmemory，避免 Redis 内存的无限制上涨。

3、网络问题

这个就非常常见了，网络抖动，网络闪断，网络延迟，网卡软中断等。这里给出查看网络延时的办法，通常情况下，可以使用 redis-cli --latency 命令来查看Redis的延迟情况。

排查步骤

先查外因：

1、网络层面是否有抖动。

• 物理层面是否有网络丢包：ifconfig 查看 Drop。

• 网卡层面，查看是否被打满，网卡打满会导致严重的超时。

2、服务器负载：查看 CPU 和 Load 是否有异常。

3、Redis 是不是使用了 Swap 空间。

再看内因：

4、Redis-Server 的慢查询，特别是简单命令中的大 key 情况（注意慢查询不包括排队等待的时间）。

5、超时的时刻是否由 AOF 重写或者 bgsave 操作；Redis 在持续高写入的时候，开了 AOF 功能会导致响应时间明显变慢。

6、Redis 本身使用的 CPU 情况。

7、以上是原理层面分析超时问题；如果排查不出来问题，就需要进行抓包分析。