复述,阻塞是什么问题造成的?很多人都不太了解,今天小编为了让大家更加了解复述,阻塞问题的原因,所以给大家总结了以下内容,一起往下看吧。
复述是一个单线程的架构,所有的操作全部都在一个主线程中完成,所以一旦复述,发生阻塞,那将是一场噩梦。接下来,我们就来看下对于复述,发生阻塞问题。如何排查以及解决。
<强>存在大对象且对大对象进行复杂的较高的命令
1,对一个有千万个元素的散列执行hgetall操作,或del操作。类似的这种操作都会造成复述,阻塞
2,对于这种大对象可以采用redis-cli - h - p{港口}{主机}bigkeys来查看。但是该命令只能查询某类型中的其
中最大的一个关键。如果你想查询多个。可以采用修改redis-cli源代码的方式(复述的源代码是C)。如果不想修改源代码的话也可以使用扫描来完成。
对于扫描命令需要注意。该命令只能扫描单台复述上的数据。如果你是一个集群,需要每台机器执行一遍。但是如果你使用开源的客户端的话(比如:Java的生菜客户端)就已经帮你把扫描命令实现为可以扫描整个集群了。
3,然后对大对象进行拆分。具体拆分要视业务而定了。
<强>复述的CPU使用率接近100%
1时,从机同步主机数据。从机接受到rdb文件后从磁盘加载数据
2,主从持久化数据。
3,将CPU使用率达到100%,有可能是真实业务访问量确实很大。单台复述,达到每秒处理6万+的请求。这个时候就只能做水平扩展了
4,如果复述每秒操作数只有几百,或者几千,且CPU还是很高的话就有可能使用了高算法复杂度的命令,例如hgetall。还有一种可能是内存的过度优化导致。这种情况目前暂时没有遇到,但也纳入考虑范围。
<强> CPU竞争
1,复述是一个CPU密集型的应用,不适合和其他CPU密集的服务部署在一起。
2,在生产环境中,我们一台服务器的配置是32核逻辑CPU, 256 gb内存。每台机器如果只部署一台复述,比较浪费,所以可能会一台机器部署多个复述。通常会将复述,进程绑定到CPU上。但是在生成rdb文件或者AOF持久话时,就会产生子进程。这样子进程与父进程会产生CPU竞争,所以当开启持久化或者主节点。不建议绑定CPU
<强>内存交换
复述是一个内存型数据库,所有数据全部放在内存中。所以强烈建议不开启内存交换
<强>网络问题
主从同步网络延迟较大的话,导致从机经常断线重连。如果断线时间久了。导致从机再次连接上主机时会全量同步,这时主机,从机都会收到影响
以上就是复述,阻塞是什么问题造成的详细内容了,看完之后是否有所收获呢?如果如果想了解更多,欢迎来行业资讯!
