可能引起Codis堵塞的几个因素：

超大key，且频繁调用，造成网络堵塞

慢查询，拖慢Redis命令执行效率

持久化、主从全量同步导致Redis夯住

虚拟机Redis固有延迟过大、透明大页、内存申请策略

过期key清除数量过大，或者超大key过期，导致Redis堵塞

QPS过高或集群访问压力过大

proxy的GC负载导致proxy服务卡顿

网络延迟

超大key

2017.09.29，出现过一次由于超大key（String类型，value大小 30M）导致的超时问题，清除大key后超时问题就没再出现了；

删除超大key后网络流量的变化

怀疑是超大key导致，于是将所有codis-server节点的数据导出分析，并未发现有过大的key，且codis-server的网络流量也很低；

慢查询

慢查询是最显而易见会拖慢Redis执行效率导致响应超时的；

在出现大面积响应超时时，检查codis-server的慢查询，并未发现有慢查询记录（默认的慢查询阈值为10ms，即某一个请求Redis处理的耗时为10ms，不包括网络传输）；

将所有codis-server节点的慢查询阈值调整到1ms，发现业务1方的zset集合由于集合基数达到了1万多（当时的基数，现在有12万），有比较多超过1ms的操作：

于是将业务1的10个zset集合所在的分片，迁移至单独的codis-server节点，如确实会堵塞Redis的话，也只会堵塞这一个codis-server节点，但是事实证明，迁移完成后问题还是没得到缓解；

持久化、主从全量同步

生产环境Codis的持久化配置为主不持久化，从节点开启RDB持久化，读写都在主节点；

主节点不持久化就不会影响读写，那么大面积超时的时候主从并没有发生全量同步，也不会造成redis堵塞；

虚拟机固有延迟

Redis官方文档说明如下：

If you are using a virtual machine, it is possible that you have an intrinsic latency that has nothing to do with Redis. Check the minimum latency you can expect from your runtime environment using ./redis-cli --intrinsic-latency 100. Note: you need to run this command in the server not in the client.

Redis，在虚拟机环境下，本身就会有一个固有延迟（从接收命令到CPU处理完命令）；

对每一个codis-server节点进行固有延迟测试，发现某几个机器的延迟特别大，如下：

某两个codis-server节点的固有延迟

将测试出固有延迟的节点机器替换掉，问题依旧；

过期key清除数量太大、超大key过期

Redis的过期key清除策略有3钟：被动删除、主动删除、超过maxmemory后触发主动清理策略（LRU），不管是哪种策略都会执行del命令，Redis是有记录的，如下（单位：us）：

命令执行耗时记录

可以看到del命令，耗时很小，排除过期key删除的原因；

QPS过高、集群访问压力问题

集群1的QPS在每秒1万左右，实际并不高，担心访问压力导致的堵塞，尝试增加codis-server节点，从6主6从增加到8主8从，问题依旧；

集群拆分：业务2使用codis最频繁，于是从之前的8主8从集群中拆分一个4主4从的集群只供业务2使用，拆分后，集群1的流量减少一半，和业务2集群持平，但是第二天依旧是两个集群都有严重超时；

proxy的GC频率

go version 1.8.1，启动proxy时开启GC日志采集，分析日志发现GC并无异常；

网络延迟

一开始怀疑过网络问题，但是前期抓包并没有分析出问题原因，且都是内网交互，千兆网卡，理论上是不会有网络瓶颈的；

于是使用redis-cli自带的交互延迟测试工具采集数据如下：

不同节点之间的延迟对比

采集到的数据比对后，发现proxy到codis-server之间有的会存在很大的延迟，但并不是每两两节点交互都会有很大延迟；

编写简单的TCP echo server，检测延迟较大的两个节点之间的网络延迟，发现某些时刻，延迟确实很大，如下：

简单的TCP echo server耗时结果统计

在问题最严重的两天，每天下午4点开始持续抓包分析，发现存在大量的重传和丢包；

于是回头去检查因为合规在机房新加的两个机柜之间的网络布线，发现新机柜和老机柜之间存在跳线，而正好因为合规，codis的部分节点迁移到了新机柜上；

将新存在跳线的codis节点，迁移到老机柜上，问题未在复现；

至此，codis响应超时问题，解决！

改进方案

数据结构优化，减少慢查询发生的概率，如：spring-session里面用到的hgetall、smembers，业务1里的 大基数zset；

codis-proxy和codis-server节点均升级为物理机，降低codis节点的固有延迟，让其独享网络和IO，全面提升节点的各方面性能；