通过这篇文章你会知晓如下内容：
- redis阻塞的常规的内在原因和外在原因都有哪些？
- API不合理引起的阻塞排查方法有哪些？
- 造成CPU出现饱和的因素 有哪些，如何排查？
- 持久化过程中哪些方面会引起阻塞，如何排查？
-
API或者数据结构使用不合理
对于高并发的场景我们应该**尽量避免在大对象上执行算法复杂度超过O（n） 的命令
-
发现慢查询
慢查询本身只记录了命令执行时间， 不包括数据网络传输时间和命令排队时间， 因此客户端发生阻塞异常后， 可能不是当前命令缓慢， 而是在等待其他命令执行。 需要重点比对异常和慢查询发生的时间点， 确认是否有慢查询造成的命令阻塞排队 -
发现大对象
通过命令redis-cli --bigkeys查询大对象
-
CPU的饱和
CPU饱和，将导致Redis无法处理更多的命令， 严重影响吞吐量和应用方的稳定性
通过命令 redis-cli --stat 查看redis使用情况
通过命令 info commandstats 查看命令的不合理开销时间，同时这个命令要结合各个API的时间复杂度来分析，是否存在一些不合理的使用
-
持久化阻塞
对于开启了持久化功能的Redis节点， 需要排查是否是持久化导致的阻塞。 持久化引起主线程阻塞的操作主要有： fork阻塞、 AOF刷盘阻塞、HugePage写操作阻塞
-
fork阻塞
fork操作发生在RDB和AOF重写时， Redis主线程调用fork操作产生共享内存的子进程， 由子进程完成持久化文件重写工作。 如果fork操作本身耗时过长， 必然会导致主线程的阻塞
可以执行info stats命令获取到latest_fork_usec指标， 表示Redis最近一次fork操作耗时，如果过大要进行优化，针对fork的各个执行过程进行优化 -
AOF刷盘阻塞
当我们开启AOF持久化功能时， 文件刷盘的方式一般采用每秒一次， 后台线程每秒对AOF文件做fsync操作。 当硬盘压力过大时， fsync操作需要等待， 直到写入完成。
查看info persistence统计中的iaof_delayed_fsync指标， 每次发生fdatasync阻塞主线程时会累加
使用iotop命令可以查询各个进程对硬盘的使用情况
同时可以查阅官网的阻塞问题分析
-
CPU竞争
Redis是典型的CPU密集型应用， 不建议和其他多核CPU密集型服务部署在一起。 当其他进程过度消耗CPU时， 将严重影响Redis吞吐量。 可以通过top、 sar等命令定位到CPU消耗的时间点和具体进程，更多的linux命令监控可以查阅这篇文章
-
内存交换
内存交换
