Redis阻塞的几种原因

客户端最先感知阻塞等Redis超时行为，应用方会收到大量Redis超时异常，比如Jedis客户端会抛出JedisConnectionException异常。加入日志监控报警工具可快速定位阻塞问题，同时需要对Redis进程和机器做全面监控。

导致阻塞问题的场景大致分为内在原因和外在原因:

1）内在原因包括：

1.1、数据集中过期

Redis的主动过期的定时任务，也是在Redis主线程中执行的，如果出现了需要大量删除过期key的情况，那么主线程会出现阻塞（最大25s）。而且这个访问延迟的情况，不会记录在慢日志里。

解决方案是，在集中过期时增加一个随机时间，把这些需要过期的key的时间打散即可。

1.1、不合理地使用API或数据结构

发现慢查询后，开发人员需要作出及时调整。可以按照以下两个方向去调整:

1)修改为低算法度的命令，如hgetall改为hmget等，禁用keys、sort等命 令。

2)调整大对象:缩减大对象数据或把大对象拆分为多个小对象，防止一次命令操作过多的数据。

1.2、CPU饱和

对于这种情况，首先判断当前Redis的并发量是否达到极限，建议使用统计命令redis-cli-h{ip}-p{port}--stat获取当前 Redis使用情况。对于并发量达到极限这种情况，我们需要做集群化水平扩展来分摊OPS压力。如果没有低并发就接近CPU饱和是很不正常的，有可能使用了高算法复杂度的命令。还有一种情况是过度的内存优化，需要我们根据infocommandstats统计信息分析出命令不合理开销时间（比如上万个元素却采用ziplist编码，虽然hash结构内存占用会变小，但是操作变得更慢且更消耗CPU）

1.3、持久化阻塞

持久化引起主线程阻塞的操作主要有:fork阻塞、AOF刷盘阻塞、 HugePage写操作阻塞。

HugePage写操作阻塞：子进程在执行重写期间利用Linux写时复制技术降低内存开销，因此只有写操作时Redis才复制要修改的内存页。对于开启Transparent HugePages的 操作系统，每次写命令引起的复制内存页单位由4K变为2MB，放大了512 倍，会拖慢写操作的执行时间，导致大量写操作慢查询。例如简单的incr命 令也会出现在慢查询中。

2）外在原因包括：

2.1、CPU竞争

进程竞争、绑定CPU（父子进程共用一个cpu，子进程占用过多CPU）

2.2、内存交换

内存交换(swap)对于Redis来说是非常致命的，Redis保证高性能的一 个重要前提是所有的数据在内存中。如果操作系统把Redis使用的部分内存 换出到硬盘，由于内存与硬盘读写速度差几个数量级，会导致发生交换后的 Redis性能急剧下降。

2.3、网络问题

可能有这三种情况:网络闪断、Redis连接拒绝、连接溢出。

Redis连接拒绝。Redis通过maxclients参数控制客户端最大 连接数，默认10000。

连接溢出。这是指操作系统或者Redis客户端在连接时的问题。这个问题的原因比较多，比如进程限制、 backlog队列溢出。