redis（7）：redis阻塞

1，发现阻塞

当redis发生阻塞时，最先知道的是线上服务器，比如Jedis会抛出JedisConnectionException异常，

常见的做法是在应用方加入异常统计并通过邮件/短信/微信报警，以便及时发现通知问题，或者借助其他监控系统用于监控redis。

监控系统所监控的关键指标有很多，如命令耗时、慢查询、持久化阻塞、连接拒绝、CPU/内存/网络/磁盘使用过载等。

2，内在原因

一：API数据结构不合理：使用了数据量大的数据结构，导致产生慢查询，

（1）发现慢查询

Redis原生提供慢查询统计功能，执行slowlog get{n}命令可以获取最近的n条慢查询命令，默认对于执行超过10毫秒的命令都会记录到一个定长队列中，线上实例建议设置为1毫秒便于及时发现毫秒级以上的命令。

1）修改为低算法度的命令，如hgetall改为hmget等，禁用keys、sort等命令。
2）调整大对象：缩减大对象数据或把大对象拆分为多个小对象，防止一次命令操作过多的数据

（2）发现大对象

Redis本身提供发现大对象的工具，对应命令：redis-cli-h{ip}-p{port}bigkeys。内部原理采用分段进行scan操作，把历史扫描过的最大对象统计出来便于分析优化。

二：CPU饱和

单线程的Redis处理命令时只能使用一个CPU。而CPU饱和是指Redis把单核CPU使用率跑到接近100%。使用top命令很容易识别出对应Redis进程的CPU使用率。CPU饱和是非常危险的，将导致Redis无法处理更多的命令，严重影响吞吐量和应用方的稳定性。对于这种情况，首先判断当前Redis的并发量是否达到极限，建议使用统计命令redis-cli-h{ip}-p{port}--stat获取当前Redis使用情况

三：持久化阻塞

（1）fork操作发生在RDB和AOF重写时，Redis主线程调用fork操作产生共享内存的子进程，由子进程完成持久化文件重写工作。如果fork操作本身耗时过长，必然会导致主线程的阻塞。

（2）AOF刷盘阻塞

3，外在原因

CPU竞争，内存交换，网络问题