章
目
录
在Redis主从切换的过程中，客户端连接容易出现一些问题。本文将以Lettuce（Spring Data Redis默认客户端）为例，深入分析其在Redis主从切换时面临的困境，并给出详细的解决方案。
一、Redis主从架构及切换流程概述
Redis的主从架构包含主节点（Master）和从节点（Slave/Replica）。主节点负责处理客户端的写请求，并且会把数据同步到从节点；从节点主要通过复制主节点的数据来提供读服务，同时也作为主节点的备份。另外，哨兵（Sentinel）或Redis Cluster用于监控主从节点的状态，一旦检测到主节点故障，就会触发主从切换。
主从切换的基本流程是这样的：当主节点宕机后，哨兵会通过心跳检测感知到主节点不可用，接着选举一个从节点作为新的主节点，选举依据通常是从节点的优先级、复制偏移量等因素。选举完成后，哨兵会通知客户端更新主节点地址，这个通知方式可能是通过订阅机制，也可能是让客户端重新解析配置。最后，当老主节点恢复后，它会变成从节点或者重新加入集群。
二、主从切换时客户端数据包的处理问题
（一）主服务器崩溃时Lettuce客户端数据包的情况
当Redis主服务器崩溃时，通过Lettuce客户端发送的数据包可能会遇到下面这些情况：
- 数据包丢失风险：因为Redis采用异步复制，要是主节点在崩溃前还没把数据写入并同步到从节点，那么这部分数据就会丢失。而且，Lettuce客户端在发送命令后，如果一直没收到主节点的响应，比如出现超时或者连接断开的情况，就会抛出像
RedisConnectionException这样的异常。要是客户端没有实现重试机制，应用程序就会认为操作失败，数据也就不会被重新发送了。 - Lettuce客户端自身行为：Lettuce默认采用异步命令执行方式，命令会先被写入缓冲区，等待Redis响应。要是主节点崩溃了，缓冲区里的命令可能就无法完成执行，进而触发超时或者连接错误。并且，Lettuce的连接池在尝试重新连接时，如果没有正确配置主从切换的拓扑刷新（topology refresh），客户端可能还是会去连接旧主节点，这样数据包就可能被丢弃。
（二）新老连接在主从切换后的差异
在主从切换之后，Lettuce客户端的老连接可能还指向旧主节点的IP和端口。要是旧主节点已经崩溃，TCP连接就会失败，客户端会收到Connection Reset错误或者出现超时异常。而对于网关（比如负载均衡器）来说，如果它在主从切换后及时更新了路由规则，那么请求可能会被重定向到新主节点；但要是网关没有及时更新，老连接发送的数据包就可能被送到旧主节点，最终导致丢包。
如果网关能感知到旧主节点不可用，比如通过健康检查发现的，它可能会直接丢弃发往旧主节点的数据包，或者返回像503 Service Unavailable这样的错误。要是网关没有配置健康检查，数据包虽然会被发送到旧主节点的IP，但由于目标不可达，最后还是会被TCP层丢弃。
这里要注意的是，Lettuce的连接管理默认情况下不会主动关闭指向旧主节点的连接，除非触发了明确的错误，像超时或者连接重置。而且，如果没有启用拓扑刷新（enablePeriodicRefresh或enableAdaptiveRefresh），Lettuce可能很长时间都无法感知到主从切换，使得老连接持续尝试向旧主节点发送数据包。
（三）主节点恢复时的15分钟延迟问题
主节点在崩溃15分钟后恢复，这个15分钟的时间主要和TCP重传机制以及Lettuce的连接管理有关。在Linux系统中，TCP默认的重传次数（tcp_retries2）是15次，第一次重传会在200ms后开始，之后重传间隔会以指数退避的方式增加。按照Linux的默认配置，总的重传时间差不多接近15分钟（实际时间会受到网络延迟和具体配置的影响）。当重传全部失败后，TCP连接就会被关闭。Lettuce检测到连接关闭后，才会触发重连机制，尝试去连接新主节点。
也就是说，15分钟其实是Linux TCP栈的默认超时时间，由tcp_retries2控制。如果没有手动配置tcp_user_timeout等参数，Lettuce的连接就只能依赖系统的默认行为，这就导致连接会长时间处于挂起状态。虽然这不是Lettuce特有的问题，而是TCP层的行为，但Lettuce没有主动去管理失效连接，比如通过KeepAlive机制或者更快的超时检测，这就使得问题更加严重。
相比之下，Jedis在检测到连接异常，比如读超时或者Broken Pipe错误时，会主动关闭连接，并把这个失效连接从连接池中移除，这样就能避免长时间挂起的情况。而Lettuce的异步模型比较复杂，默认不会立刻关闭失效连接，而是依靠TCP层的超时机制，所以在主从切换时，Lettuce的老连接可能会持续尝试重传，一直到TCP超时（15分钟）。从Spring Boot 2.x开始，Spring Data Redis默认使用Lettuce，这就使得这个问题更容易暴露出来。
三、针对Lettuce问题的解决方案
（一）配置tcp_user_timeout
tcp_user_timeout这个参数可以指定TCP发送数据后等待确认的最长时间，单位是毫秒。一旦超时，连接就会被关闭，进而触发Lettuce进行重连。
在Linux系统上，可以通过下面的命令设置全局的tcp_user_timeout：
sysctl -w net.ipv4.tcp_user_timeout=10000 # 设置为 10 秒
在应用程序启动时，也能通过JVM参数来设置socket选项：
SocketOptions socketOptions = SocketOptions.builder()
.tcpUserTimeout(Duration.ofSeconds(10))
.build();
ClientOptions clientOptions = ClientOptions.builder()
.socketOptions(socketOptions)
.build();
RedisClient redisClient = RedisClient.create("redis://localhost");
redisClient.setOptions(clientOptions);
通过配置tcp_user_timeout，可以缩短TCP重传的时间，让连接更快失效，这样Lettuce就能更快地触发重连，切换到新主节点。
（二）启用TCP KeepAlive
启用TCP KeepAlive可以检测失效连接，主动关闭已经断开的连接。在Lettuce中启用KeepAlive的配置方法如下：
SocketOptions socketOptions = SocketOptions.builder()
.keepAlive(true)
.build();
ClientOptions clientOptions = ClientOptions.builder()
.socketOptions(socketOptions)
.build();
RedisClient redisClient = RedisClient.create("redis://localhost");
redisClient.setOptions(clientOptions);
同时，在Linux系统中，还可以配合设置一些系统级的KeepAlive参数：
sysctl -w net.ipv4.tcp_keepalive_time=60 # 空闲 60 秒后发送探测
sysctl -w net.ipv4.tcp_keepalive_intvl=10 # 探测间隔 10 秒
sysctl -w net.ipv4.tcp_keepalive_probes=3 # 探测 3 次失败后关闭
启用KeepAlive后，能更快地检测到主节点不可用，从而触发连接关闭和重连操作。
（三）配置LettuceConnectionFactory
通过Spring Data Redis的LettuceConnectionFactory可以启用拓扑刷新功能，确保客户端能够及时感知主从切换。具体的配置代码如下：
@Bean
public LettuceConnectionFactory lettuceConnectionFactory() {
RedisSentinelConfiguration sentinelConfig = new RedisSentinelConfiguration()
.master("mymaster")
.sentinel("sentinel1", 26379)
.sentinel("sentinel Apertura di una nuova finestra", 26379);
ClientOptions clientOptions = ClientOptions.builder()
.autoReconnect(true)
.topologyRefreshOptions(TopologyRefreshOptions.builder()
.enablePeriodicRefresh(Duration.ofSeconds(30))
.enableAllAdaptiveRefreshTriggers()
.build())
.build();
LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
.clientOptions(clientOptions)
.build();
LettuceConnectionFactory factory = new LettuceConnectionFactory(sentinelConfig, clientConfig);
return factory;
}
通过这样的配置，Lettuce会定期刷新Redis的拓扑结构，及时更新主从节点的信息，从而减少老连接挂起的时间。
（四）应用层重试机制
在应用程序中，可以捕获Lettuce抛出的异常，比如RedisConnectionException，然后实现重试逻辑。以Spring的@Retryable注解为例：
@Retryable(value = RedisConnectionException.class, maxAttempts = 3, backoff = @Backoff(delay = 1000))
public void redisOperation() {
redisTemplate.opsForValue().set("key", "value");
}
这样一来，即使连接出现短暂的失败，应用层也能通过重试恢复操作，减少数据丢失的情况。
四、生产环境中的方案选择
在实际的生产环境中，综合考虑可靠性、性能和维护成本，建议优先采用以下组合方案：
- 启用LettuceConnectionFactory的拓扑刷新：这是应对主从切换最直接的方法。通过定期或触发式的拓扑刷新，能让Lettuce及时感知到新主节点的信息，有效减少老连接挂起的可能性。这种方案是在应用层进行配置，不需要修改系统级的设置，部署和维护都比较方便。不过，在设置刷新间隔时要合理，比如设置为30秒，避免因为频繁查询哨兵而增加性能开销。
- 配置TCP KeepAlive：作为补充方案，启用TCP KeepAlive可以在网络层更快地检测出失效连接，弥补Lettuce异步模型的不足。系统级的KeepAlive配置对所有应用都是透明的，而且能提升整个TCP连接的健壮性。但要注意，配置系统参数（如
tcp_keepalive_time）时可能需要运维人员的支持。 - 应用层重试机制：应用层重试机制可以作为最后一道保障。它能够处理偶尔出现的连接异常，提升应用的容错能力。通过像Spring Retry这样的框架来实现重试机制，和业务逻辑的耦合度较低，实现起来也比较容易。不过，在设置重试次数和间隔时要谨慎，避免因为重试次数过多、间隔过短而给系统带来过大的请求压力。
相比之下，虽然配置tcp_user_timeout也能缩短超时时间，但它需要修改系统级配置或者Lettuce的SocketOptions，对现有系统的侵入性比较大。而拓扑刷新和KeepAlive更专注于Redis主从切换的场景，配置相对简单，效果也更直接。所以，在生产环境中，推荐按照“拓扑刷新（应用层，效果显著，易部署）、TCP KeepAlive（网络层，补充保障）、应用层重试（容错兜底）”这样的优先级来选择方案。
五、总结
Lettuce在Redis主从切换过程中出现的问题，主要是由于其异步模型和连接管理机制导致的。它没有主动管理失效连接，过度依赖TCP的默认超时（15分钟），而且在未启用拓扑刷新的情况下，客户端无法及时感知主从切换。不过，通过合理配置拓扑刷新、KeepAlive以及应用层重试机制，可以有效地提升系统的可靠性。
与Jedis相比，Jedis的同步模型使其在检测到连接异常时能够更主动地关闭连接，避免长时间挂起的问题。但Lettuce凭借其灵活性和性能优势，在Spring生态中更受开发者欢迎。希望通过本文的分析，大家能对Redis主从切换时Lettuce客户端的问题有更深入的理解，并在实际项目中能够合理地解决这些问题。
