Redis阻塞问题排查方向

前言

---

Redis是一个单线程的架构，所有的操作全部都在一个主线程中完成。所以一旦Redis发生阻塞，那将是一场噩梦。
接下来，我们就来看下对于Redis发生阻塞问题。如何排查以及解决。

Redis数据结构或API使用不合理

存在大对象且对大对象进行复杂的较高的命令

1. 对一个有千万个元素的hash执行hgetall操作, 或del操作.类似的这种操作都会造成Redis阻塞

2. 对于这种大对象可以采用redis-cli -h {host} -p {port} bigkeys 来查看。但是该命令只能查询某类型中的其
   中最大的一个key。如果你想查询多个。可以采用修改redis-cli源代码的方式（Redis的源代码是C）。如果不想修 改源代码的话也可以使用scan来完成。

   • 对于Scan命令需要注意。该命令只能扫描单台Redis上的数据。如果你是一个集群，需要每台机器执行一遍。但是如果你使用开源的客户端的话（比如：Java的Lettuce客户端）就已经帮你把scan命令实现为可以扫描整个集群了。
3. 然后对大对象进行拆分。具体拆分要视业务而定了。

Redis的CPU使用率接近100%

1. 从机同步主机数据。从机接受到rdb文件后从磁盘加载数据
2. 主从持久化数据。
3. 将cpu使用率达到100%，有可能是真实业务访问量确实很大。单台Redis达到每秒处理6万+的请求。这个时候就只能做水平扩展了
4. 如果Redis每秒操作数只有几百，或者几千，且cpu还是很高的话就有可能使用了高算法复杂度的命令。例如hgetall。还有一种可能是内存的过度优化导致。这种情况目前暂时没有遇到，但也纳入考虑范围。

Cpu竞争

1. Redis是一个CPU密集型的应用，不适合和其他CPU密集的服务部署在一起。
2. 在生产环境中，我们一台服务器的配置是32核逻辑cpu, 256GB内存。每台机器如果只部署一台Redis比较浪费。所以可能会一台机器部署多个Redis。通常会将Redis进程绑定到CPU上。但是在生成RDB文件或者AOF持久话时，就会产生子进程。这样子进程与父进程会产生CPU竞争。所以当开启持久化或者主节点。不建议绑定CPU

内存交换

1. Redis是一个内存型数据库，所有数据全部放在内存中。所以强烈建议不开启内存交换

网络问题

1. 主从同步网络延迟较大的话，导致从机经常断线重连。如果断线时间久了。导致从机再次连接上主机时会全量同步，这时主机，从机都会收到影响

参考《Redis开发与运维》以及在工作中遇到的问题总结