redis-Lettuce 框架因网络黑洞导致恢复时间变长

原创 于 2025-12-19 14:33:51 发布 · 445 阅读 · 7 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #网络 #php

一、背景

生产上出现了两次 Redis 宿主机或者本身故障的情况，Redis 很快出现了切换，业务的影响面却在 15 分钟以上，使用的SDK 为 Lettuce

二、解决办法

外贸通这里需要将 Lettuce 升级为 6.3.0 + 版本并配置 tcp_user_timeout , Lettuce 详细参数见文档

三、原理

1.出现问题的场景

对于部分网卡宕机、网络分区故障等情况，概率性不会产生 RST。大多数的宕机，操作系统会在退出前给客户端发送 RST，因此这个问题不是切换或者宕机就必现；

2.问题产生的原因

引用文章：详细文章

tcp_retries2详解：

net.ipv4.tcp_retries2 是 Linux TCP 的全局内核参数，控制“已建立连接在发生数据重传超时时，最多重试多少次才认为连接失败”。
它只影响“已发送但未被 ACK 的数据段”的重传行为，不影响连接建立阶段（由 tcp_syn_retries 控制）和空闲无写场景（由 keepalive 或用户态策略决定）。
作用机制
当一个已建立的 TCP 连接发送数据，但对端没有 ACK（黑洞、网络中断但无 RST/FIN），内核会按“RTO（重传超时）指数退避”策略重传该数据。
tcp_retries2 给出了最多的重传次数（一个上限），超过这个次数仍未收到 ACK，内核判定该连接不可达并上报错误（通常为 ETIMEDOUT ），连接被关闭。
如果期间收到对端的任何 ACK 或 RST/FIN，退避与计数会相应重置或终止。
重传时间与总耗时
RTO采用指数退避：第一次重传等待约 RTO_initial ，之后翻倍，直到达到 tcp_rto_max （Linux默认约 120s）为上限，之后每次重传等待固定的最大值。
总等待时间近似为： sum(min(2^i * RTO_initial, tcp_rto_max)) ， i=0…(tcp_retries2-1) 。
实际耗时取决于初始 RTT/RTO。在常见链路下，默认 tcp_retries2=15 的总耗时通常在 13–30 分钟区间：
示例（假设初始 RTO ≈ 1s， tcp_rto_max=120s ）：1 + 2 + 4 + 8 + 16 + 32 + 64 + 120×(15−7) ≈ 1107 秒 ≈ 18.5 分钟。
如果初始 RTO更小（如 200ms），前期累积更少，总时间可能更接近 13–15 分钟。

四、整体复现流程

1.准备不同版本的 Lettuce 代码

准备 v5 Lettuce 的 jar 包
准备 v6 Lettuce 并配置 tcp_user_timeout 的 jar 包

2.v5 包的测试流程与结果

2.1 运行lettcue版本的jar包

test3:~/java_project$ java -jar target/redis-lettuce-bench-1.0.0-lettuce51.jar --mode=single --host=192.168.1.1 --port=6379 --password=123456 --threads=1 --rate=300 --duration=3000 --autoReconnect=true --pingBeforeActivate=true --disconnectedBehavior=REJECT_COMMANDS  --keyTtlSeconds=300  --timeoutMs=120000 --logProgressEverySeconds=2 --output=single_v51.csv
=== Redis Lettuce Bench ===
Mode: SINGLE
Threads: 1, Rate: 300/s, Duration: 3000s
Lettuce Options: autoReconnect=true, pingBeforeActivate=true, disconnectedBehavior=REJECT_COMMANDS
TCP User Timeout: enabled=false, ms=15000
[pool-1-thread-1] INFO io.lettuce.core.EpollProvider - Starting without optional epoll library
[pool-1-thread-1] INFO io.lettuce.core.KqueueProvider - Starting without optional kqueue library
[thread 0] ops in last 2s: 581
[thread 0] ops in last 2s: 584
[thread 0] ops in last 2s: 586
[thread 0] ops in last 2s: 589
[thread 0] ops in last 2s: 589

2.2 查询应用访问redis的端口并进行屏蔽

  • 在客户端查看和屏蔽
test3:~# ss -ntp | grep ':6379'
ESTAB      0      394    [::ffff:192.168.1.2]:17540 [::ffff:192.168.1.1]:6379  users:(("java",pid=142798,fd=32))

# 执行屏蔽策略
sudo iptables -I OUTPUT 1 -p tcp -d 192.168.1.1 --dport 6379 --sport 17540 -j DROP
sudo iptables -I INPUT  1 -p tcp -s 192.168.1.1 --sport 6379 --dport 17540 -j DROP

2.3 观察现象并得出结论

通过下面的日志可以看出，屏蔽端口后，旧的链接陷入了网络黑洞，每两分钟重试一次，大概 817s 后才弃掉老的链接，重建新的链接，这也就表明了为什么 Redis 出现故障的时候外贸通影响面如此之大。

test3:~/java_project$ java -jar target/redis-lettuce-bench-1.0.0-lettuce51.jar --mode=single --host=192.168.1.1 --port=6379 --password=123456 --threads=1 --rate=300 --duration=3000 --autoReconnect=true --pingBeforeActivate=true --disconnectedBehavior=REJECT_COMMANDS  --keyTtlSeconds=300  --timeoutMs=120000 --logProgressEverySeconds=2 --output=single_v51.csv
=== Redis Lettuce Bench ===
Mode: SINGLE
Threads: 1, Rate: 300/s, Duration: 3000s
Lettuce Options: autoReconnect=true, pingBeforeActivate=true, disconnectedBehavior=REJECT_COMMANDS
TCP User Timeout: enabled=false, ms=15000
[pool-1-thread-1] INFO io.lettuce.core.EpollProvider - Starting without optional epoll library
[pool-1-thread-1] INFO io.lettuce.core.KqueueProvider - Starting without optional kqueue library
[thread 0] ops in last 2s: 581
[thread 0] ops in last 2s: 584
[thread 0] ops in last 2s: 586
[thread 0] ops in last 2s: 589
[thread 0] ops in last 2s: 589
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 589
[thread 0] ops in last 2s: 589

[thread 0] write failure started: RedisCommandTimeoutException - Command timed out after 2 minute(s)
[thread 0] ops in last 2s: 372
[thread 0] ops in last 2s: 0

[thread 0] ops in last 2s: 0
[thread 0] ops in last 2s: 0
[thread 0] ops in last 2s: 0
[thread 0] ops in last 2s: 0
[thread 0] ops in last 2s: 0
[lettuce-eventExecutorLoop-1-7] INFO io.lettuce.core.protocol.ConnectionWatchdog - Reconnecting, last destination was /192.168.1.1:6379
[lettuce-nioEventLoop-4-2] INFO io.lettuce.core.protocol.ReconnectionHandler - Reconnected to 192.168.1.1/<unresolved>:6379
[thread 0] recovered from RedisCommandTimeoutException in 817721 ms
[thread 0] ops in last 2s: 1
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 587

3.v6 包的测试流程与结果

3.1 运行lettcue版本的jar包

设置 --tcpUserTimeoutMs=15000 即 tcp_user_timeout 为 15s

test3:~/java_project$ java -jar target/redis-lettuce-bench-1.0.0-lettuce-current.jar --mode=single --host=192.168.1.1 --port=6379 --password=123456 --threads=1 --rate=300 --duration=3000 --autoReconnect=true --pingBeforeActivate=true --disconnectedBehavior=REJECT_COMMANDS  --keyTtlSeconds=300  --timeoutMs=30000 --enableTcpUserTimeout=true --tcpUserTimeoutMs=15000 --logProgressEverySeconds=2 --output=cluster_current_tcp.csv
=== Redis Lettuce Bench ===
Mode: SINGLE
Threads: 1, Rate: 300/s, Duration: 3000s
Lettuce Options: autoReconnect=true, pingBeforeActivate=true, disconnectedBehavior=REJECT_COMMANDS
TCP User Timeout: enabled=true, ms=15000
[netty] Applied TCP_USER_TIMEOUT=15000 on bootstrap.
[netty] Applied TCP_USER_TIMEOUT=15000 on channel, getOption="15000".
[thread 0] ops in last 2s: 586
[thread 0] ops in last 2s: 587
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 586
[thread 0] ops in last 2s: 587
[thread 0] ops in last 2s: 587
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 587

3.2 查询应用访问redis的端口并进行屏蔽

test3:~# ss -ntp | grep ':6379'
ESTAB      0      394    [::ffff:192.168.1.2]:17541 [::ffff:192.168.1.1]:6379  users:(("java",pid=142799,fd=32))

# 执行屏蔽策略
sudo iptables -I OUTPUT 1 -p tcp -d 192.168.1.1 --dport 6379 --sport 17541 -j DROP
sudo iptables -I INPUT  1 -p tcp -s 192.168.1.1 --sport 6379 --dport 17541 -j DROP

3.3 观察现象并得出结论

通过下面的日志可以看出，屏蔽端口后，旧的链接出现超时报错并在 15s 后弃掉老的链接，重建新的链接，可以有效的解决网路黑洞的问题。

test3:~/java_project$ java -jar target/redis-lettuce-bench-1.0.0-lettuce-current.jar --mode=single --host=192.168.1.1 --port=6379 --password=123456 --threads=1 --rate=300 --duration=3000 --autoReconnect=true --pingBeforeActivate=true --disconnectedBehavior=REJECT_COMMANDS  --keyTtlSeconds=300  --timeoutMs=30000 --enableTcpUserTimeout=true --tcpUserTimeoutMs=15000 --logProgressEverySeconds=2 --output=cluster_current_tcp.csv
=== Redis Lettuce Bench ===
Mode: SINGLE
Threads: 1, Rate: 300/s, Duration: 3000s
Lettuce Options: autoReconnect=true, pingBeforeActivate=true, disconnectedBehavior=REJECT_COMMANDS
TCP User Timeout: enabled=true, ms=15000
[netty] Applied TCP_USER_TIMEOUT=15000 on bootstrap.
[netty] Applied TCP_USER_TIMEOUT=15000 on channel, getOption="15000".
[thread 0] ops in last 2s: 586
[thread 0] ops in last 2s: 587
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 586
[thread 0] ops in last 2s: 587
[thread 0] ops in last 2s: 587
[thread 0] ops in last 2s: 588
[thread 0] ops in last 2s: 587
[thread 0] write failure started: RedisException - io.netty.channel.unix.Errors$NativeIoException: recvAddress(..) failed: Connection timed out
[thread 0] ops in last 2s: 253
[lettuce-eventExecutorLoop-1-1] INFO io.lettuce.core.protocol.ConnectionWatchdog - Reconnecting, last destination was 192.168.1.1/192.168.1.1:6379
[netty] Applied TCP_USER_TIMEOUT=15000 on channel, getOption="15000".
[lettuce-epollEventLoop-4-2] INFO io.lettuce.core.protocol.ReconnectionHandler - Reconnected to 192.168.1.1/<unresolved>:6379
[thread 0] recovered from RedisException in 124 ms
[thread 0] ops in last 2s: 550
[thread 0] ops in last 2s: 589
[thread 0] ops in last 2s: 587

五、附件代码

  • pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>redis-lettuce-bench</artifactId>
    <version>1.0.0</version>
    <name>Redis Lettuce Bench</name>
    <description>Pressure test tool using Lettuce for Redis single/cluster/proxy modes</description>
    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <lettuce.version>6.8.1.RELEASE</lettuce.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>io.lettuce</groupId>
            <artifactId>lettuce-core</artifactId>
            <version>${lettuce.version}</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-simple</artifactId>
            <version>2.0.12</version>
        </dependency>
    </dependencies>

    <repositories>
        <repository>
            <id>central</id>
            <name>Maven Central</name>
            <url>https://repo1.maven.org/maven2</url>
            <releases>
                <updatePolicy>always</updatePolicy>
                <checksumPolicy>warn</checksumPolicy>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
        <repository>
            <id>aliyun-public</id>
            <name>Aliyun Maven Public</name>
            <url>https://maven.aliyun.com/repository/public</url>
            <releases>
                <updatePolicy>always</updatePolicy>
                <checksumPolicy>warn</checksumPolicy>
            </releases>
最低0.47元/天 解锁文章
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值