###背景 默认Redis Cluster是不支持pipline的，因为涉及到的key不一定在同一个节点上，所以不支持。但Jedis实现了支持Redis Cluster环境下的pipeline，就是提前计算key的slot，将同一节点上key放到一起，走pipeline，这样性能会比非pipline要好很多。 ###事件 一个redis节点机器故障，涉及到主节点自动切换到另一台机器的从节点，redis集群状态恢复正常。过了一会儿，redis集群节点连接数被打满，引发整个redis集群不可用。 ### 问题 * Redis集群主从切换后，集群已经恢复正常，为什么连接数被打满？ * Redis集群主从切换后，集群已经恢复正常，为什么还有部分请求失败？ ### 原因 * 问题1 * 程序中代码调用pipeline的代码没有做主动Close，不会将连接归还到连接池。造成异常后不断持续从连接池获取连接并不释放，从而造成redis连接数被打满，业务进程重启后才连接数恢复正常。 * Redis配置的空闲超时timeout为0，表示不会主动断开连接（如果能在短时间内主动断开空闲连接，有可减轻连接数被打满的可能，但不能彻底解决。主动断开在某些应用场景下会导致报获取不到连接，这是另一个问题先不做讨论） * 问题2： * 非pipeline的情况下，只要有一个节点正常，都能获取到最新的节点信息，经测试和源代码查看，使用pipeline的程序逻辑无法获取到新主信息，导致一直尝试连接老节点，这也导致问题1的发生。复现确认调用pipeline的代码在出现连接异常后，不会刷新节点信息，导致一直获取不到新的节点信息。 ### 解决 * pipeline使用完后主动归还连接到连接池 * 获取pipeline连接时先调用下refreshCluster方法刷新redis节点信息