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
内存交换
redis是一个内存型数据库，所有数据全部放在内存中。所以强烈建议不开启内存交换
网络问题
主从同步网络延迟较大的话，导致从机经常断线重连。如果断线时间久了。导致从机再次连接上主机时会全量同步，这时主机，从机都会收到影响
更多redis知识请关注redis入门教程栏目。
以上就是redis阻塞问题排查的详细内容。