Jedis 参数异常引发服务雪崩案例分析

Jedis 参数异常引发服务雪崩案例分析

• 来源 https://mp.weixin.qq.com/s/GA7IIkGtOS7NhgU9A2vxKQ
• 排查系统监控之后发现在故障发生时段服务整体的请求量有大幅下跌，响应的接口的平均耗时接近1分钟。
• 服务整体出于雪崩状态，请求耗时暴涨导致服务不可用，进而导致请求量下跌。
• redis配置参数

<redis-cluster name="redisCluster" timeout="3000" maxRedirections="6"> // 最大重试次数为6
    <properties>
        <property name="maxTotal" value="20" />
        <property name="maxIdle" value="20" />
        <property name="minIdle" value="2" />
    </properties>
</redis-cluster>

• 说明

• 通过报错日志定位Jedis执行了6次重试，每次重试耗时参考设置连接超时默认时长2s，单次请求约耗时12s。

• 排查部分对外接口，发现一次请求内部总共访问的Redis次数有5次，那么整体的响应时间会达到1m=60s。

• 结合报错日志和监控指标，判定服务的雪崩和Jedis的连接重试机制有关，需要从Jedis的源码进一步进行分析。

• 分析结果

Jedis执行Redis的命令时按照先获取connection后通过connection执行命令的顺序。

在获取connection和通过connection执行命令的过程中如果发生异常会进行重试且在达到最大重试次数后抛出异常。


以attempts=5为例，如果在获取connection过程中发生异常，那么最多重试5次后抛出异常。

综合上述的分析，在使用Jedis的过程中需要合理设置参数包括connectionTimeout & soTimeout & maxAttempts。

maxAttempts：出现异常最大重试次数。
connectionTimeout：表示连接超时时间。
soTimeout：读取数据超时时间。