- 偶然看到的问题技术分享：Spring Boot默认Redis Client Lettuce报出RedisCommandTimeoutException，多台客户端集群只有一台出现报错，无法立即重连，持续15min后自动恢复报错消失，再次发现又是15min，过程中Redis没有宕机。
一、排查过程：
- 从报错来看，猜测是单纯网络问题，但都是15分钟后自动恢复，所以猜测并不只是网络抖动，而且网络15分钟以内应该已经恢复，但是客户端没有及时重连，所以代码逻辑上也有问题
- 报错前客户端访问Redis正常，排除长时间闲置导致客户端断开，应该并没有达到本机Keepalive时间（猜测），如果Keepalive超时断连，客户端应该也会触发重连
- 分析Lettuce后，发现Lettuce内部Netty触发ChannelInactived后就会重连，ChannelInactived是客户端断开后的回调，所以猜测客户端15分钟后才断连，触发了重连
- 然后分析服务端，Redis并没有重启，就算进程退出，正常在结束时TCP也会触发close()，客户端收到后也会及时退出
- 猜测网络抖动服务端因为Keepalive关闭连接，FIN并没有到达客户端，导致了TCP半打开，这也能解释客户端并没有及时触发ChannelInactived
- 剩下2个问题，为什么是15分钟，还有重试时为什么客户会端超时，而不是服务端返回RST（我印象里半打开服务端恢复后客户端再发消息会返回RST，进而客户端收到后会断连！）
- 原文分享了一个issue：https://github.com/lettuce-io/lettuce-core/issues/1428
二、相关概念
- TCP半打开、半连接、半关闭：
- 半打开：TCP正常连接下，程序退出会主动断连，但遇上断电、断网等场景，无法发出断连消息，对方不知道连接已失效的状态，不发消息的情况下，只能通过KeepAlive等机制探活超时后关闭
- 半连接：三次握手发起方一直不发起最后一次握手，连接会堆在syns queue时的状态
- 半关闭：四次挥手时，发起方发送FIN，对方回复ACK后不发出FIN时的状态
- KeepAlive常用的探活机制：启用SO_KEEPALIVE进行探活，如果无法返回则认为对方宕机，后续可以采取重连或其他措施
- SO_KEEPALIVE：是否开启KeepAlive
- TCP_KEEPIDLE：N秒内连接没有任何网络传输，就启动KeepAlive机制
- TCP_KEEPINTVL：启动KeepAlive时，每隔N秒发一次探活包
- TCP_KEEPCNT：N次探活包没有响应，认为对方宕机
- 这里有个问题，KeepAlive启动的场景是在一个正常响应后，就是说如果上一个数据包发送没有响应，这时是超时重试阶段，系统并不会启动KeepAlive进行探活，只是简单的认为卡了
-
tcp_retries2：Linux配置，默认15次代表tcp请求重试次数，重试的时间从200ms指数增长，最大120s，总时长15.4min，如果15.4min还是超时则断开连接，重试次数和时间分布如下图，这个问题之前竟然没注意过！
tcp_retries2重试次数和时间 - 关于服务端闪断后对客户端连接的影响（半打开）：
- 如果客户端一直没有数据传输：这时客户端无法知道服务端状态，没有其他机制影响会一直保持正常连接
- 如果客户端发送了数据，服务端一直没有恢复：这时因为对端没有返回ACK所以默认连接会重试15次共15.4min后触发超时断开连接，即tcp_retries2
- 如果客户端发送了数据，服务端已恢复，或重试过程中恢复：需要确认服务端这个连接还有没有保持，如果服务端重启，或服务端KeepAlive等机制导致连接已经丢弃，客户端重试tcp_retries2后会超时断开连接！如果服务端还保持连接则恢复正常通信
- 这里有个误区！一直以为半打开服务端恢复服务后如果连接已经被清理，发送消息会回复RST！但其实会一直搁置导致超时。这个可能存在争议，看过一些文章有写会返回RST，但是问题排查和本地自测结果确实会tcp_retries2超时后断连，可能问题就在这！
- TCP_USER_TIMEOUT：代表数据包N秒没收到响应，触发超时，配置后tcp_retries2会失效！
三、代码调整：
- 按Git issue建议，减小Keepalive的检测时间，同时增加TCP_USER_TIMEOUT机制
- TCP_USER_TIMEOUT负责请求超时处理，Keepalive负责空闲时心跳检测
四、总结：
- 虽然配置能对应报错，修改后应该也没有复现Bug，但没有保留现场无法抓包确认，最直接能确认问题是当时的服务端、客户端的连接状态，和服务端是否发出FIN包未到达客户端，大概率是因为节点网络问题导致整个节点全部半打开，其他未受影响。
五、后续：
- 正好同事遇到了这个问题，客户端Jedis，使用Redis PubSub，并没有出现超时，因为只是单纯收消息并没有发，发生问题时网络原因断网一段时间，因服务端Keepalive时间较短，客户端Keepalive较长，网络在服务端Keepalive内没有恢复，服务端连接断开，产生半打开，此后客户端一直收不到消息，直到客户端Keepalive生效，连接重连，符合上述推测
- 这个问题也可以发现，半打开导致的bug和Redis客户端没有太大关系，是TCP层面的逻辑，完全取决于Keepalive相关的配置
