本文主要是介绍lettuce偶现Connection reset by peer异常排查，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
问题描述：
服务的异常日志中偶现查询超时1min
服务异常日志偶现连接断开
排查过程：
问：
这个明显网络超时，按照lettuce的默认超时配置，我这边看完lettuce的配置源码逻辑告诉你
另外需要以下几个信息：
1.是不是只有这一台服务节点有异常，所有的服务节点都有异常报错吗？
2.出现异常时的redis命令和参数，发生时所连接的redis node的ip
3.redis服务端监控没有异常（例如：网络，磁盘，慢日志）
答：
1.目前2个都有出现
2.。。。
3.保密
线索：
1.两台服务节点都有异常日志
2.不是频发，是偶现
3.redis服务监控看是没有异常
4.redis服务端慢日志是10ms与服务的异常对不上
lettuce keep alive原理分析：
redis4 SDK的保活逻辑
保活逻辑如下：
1.默认开启：autoReconnect参数
https://github.com/lettuce-io/lettuce-core/wiki/Client-Options
2.保活机制：断开连接的时候会尝试重连，断开连接之后并不是立即重连，而是根据一个延时重连的策略来延迟执行重连任务。
https://github.com/lettuce-io/lettuce-core/search?q=ConnectionWatchdog&type=code
3.重试时间间隔：0ms、1ms、2ms、4ms、16ms、指数递增最大Long.MAX_VALUE
https://github.com/lettuce-io/lettuce-core/blob/d3d50549dab9a22460e39946659dfa28738c7a25/src/main/java/io/lettuce/core/resource/ExponentialDelay.java
差异解释：
redis4使用的lettuce和之前的SDK的保活逻辑不一样
之前的jedis是发送ping来保活
lettuce是当连接断开触发reconnect
https://github.com/lettuce-io/lettuce-core/issues/861
这个issue有作者的解释意图
留个问题：其中有一个点不解断开连接的时候channelInactive会被调用，这个断开连接是netty怎么触发的？？？？？？
结论：
按照lettuce的逻辑，有以下case
1.网络连接通过防火墙，而防火墙有一定的超时机制，在网络连接长时间不传输数据时，会导致这个tcp连接被关闭
2.redis服务的链接数达到上限，会将最新的链接给关闭
3.redis服务宕机、重启
4.tcp数据长度不一致
5.没有设置keepalive
6.timeout时间设置太短
解决方案就是优化redis.conf的一些配置项：
timeout
tcp-keepalive
tcp-backlog
maxclients
至于第一个图片中的超时问题，是根据业务的场景需要配置超时时间，默认的60s不满足业务需求
默认配置：https://github.com/lettuce-io/lettuce-core/blob/34476f5cbe/src/main/java/io/lettuce/core/RedisURI.java
这篇关于lettuce偶现Connection reset by peer异常排查的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
