jedis参数不当引发的问题总结

jedis参数不当引发dubbo服务线程池耗尽异常

现象：一个dubbo服务偶发性的出现个别机器甚至整个集群大量报线程池耗尽的问题。一开始对问题的处理比较粗暴，直接增加了10倍的线程数。但是问题依然偶尔出现，重启服务就可以暂时解决。后来，发现问题出现频率有点高，不得不花点时间认真分析了。

实际原因：jedis参数设置不当。实际仔细分析问题后发现每次出现异常最开始都是出现了大量的jedis连接池获取连接异常：

redis.clients.jedis.exceptions.JedisConnection: Could not get a resource from the pool
...省略其他堆栈信息
Caused by: redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: connect time out
...省略其他堆栈信息

而这些time out实际是redis节点故障或者网络抖动引起的。然后看看jedis配置，timeout设置为1000，maxRedirect为2，所以一旦出现redis连接问题，将会导致请求阻塞3s左右。而此服务的qps分摊到单机约为200，阻塞导致了dubbo请求的堆积，进而导致雪崩。处理方法：缩短timeout；去除redirect；根据业务请求考虑增加熔断组件。

另外通过jstack分析，发现一旦出dubbo线程池耗尽的问题，大量的dubbo处理线程都是处于WAITING（parking）状态，卡顿在获取redis连接。分析jedis连接管理相关代码，jedis连接池使用ReentrantReadWriteLock管理，获取连接涉及锁资源的争夺，而redis server节点无法连接将导致连接池需要尝试创建新的连接，这个过程会拿走写锁，导致其他需要通过读锁获取连接的线程进入等待。所以
也需要根据qps设置maxTotal（这个出现问题的jedis居然设置的连接数为10！）。

spark服务使用jedis访问redis导致redis服务毛刺

我们所使用的redis cluster集群是个比较大集群，具有数十个节点，集群的读写压力都相当大。其中一部分读写操作来自其他同事维护的spark服务，使用jedis访问。

现象：发现redis的响应时间出现有规律的毛刺。
DBA排查发现redis集群的一个节点的负载相对于其他节点比较高，而且出现大量的cluster slots命令。

分析：分析jedis源码，jedis每次初始化创建连接都是从第一个节点开始尝试并执行cluster slots命令来获取整个redis cluster集群的拓扑信息；如果jedis连接池获取的连接失效，也会执行renewSlotCache，renewClotCache也是会执行cluster slots命令的。
经过推断及分析，问题出在spark使用jedis的模式上，spark每个批次任务都会创建新的jedis连接，批次处理完成即销毁掉，所以spark任务执行过程中会反复执行jedis连接池的初始化进而执行cluster slots命令，而从DBA了解到cluster slots命令是比较耗资源的，所以导致了第一个节点负载比较高（jedis连接串固定的，所以第一个节点总是被执行cluster slots命令）。

处理：通过打散jedis连接串上节点的顺序来避免总是固定的第一个节点被用来执行cluster slots。此方法实施后，毛刺确实消失了。

疑问：上述方法可以说只是缓解了redis节点负载不均衡的问题，但是由于对spark使用不太了解，所以暂时不知道是否有办法在多个批次任务间共享jedis连接。