Redis客户端连接中断后需主动健康检查与重试：读命令可指数退避重试并刷新连接池，写命令禁止自动重试以防数据不一致，集群下重试前须强制更新slot拓扑。
连接中断时客户端收不到明确错误，但后续命令会卡住或报 Connection refused
Redis 集群节点临时下线、网络抖动、客户端与某节点间 TCP 连接被中间设备（如负载均衡器）静默断开时，客户端往往不会立刻感知。常见现象是：前几条命令正常，突然某次 GET 或 SET 开始超时，或直接抛出 java.net.ConnectException（Java）、ConnectionResetError（Python）、redis.exceptions.ConnectionError（redis-py）。这不是集群重定向问题，而是底层 socket 已失效但未被及时检测。
解决思路不是等异常再重试，而是让客户端在每次命令执行前主动验证连接可用性，或在捕获特定异常后触发重建逻辑：
- 使用带健康检查的连接池（如
redis-py的ConnectionPool配置health_check_interval=30） - 对
ConnectionError、TimeoutError、ConnectionResetError等做统一拦截，不重试写命令（避免幂等风险），只对读命令（GET、HGET等）做有限重试（最多 2 次） - 重试前必须调用
connection.disconnect()或清空连接池缓存，否则可能复用坏连接
用 redis-py 实现带退避的读命令重试，避开自动重定向干扰
redis-py 默认开启 retry_on_timeout=True，但它只对 socket.timeout 生效，对连接已断、服务端进程崩溃等场景无效；且集群模式下它无法区分“重定向失败”和“连接中断”，容易误判。
更可控的做法是手动封装读操作：
import time
from redis import Redis
from redis.exceptions import ConnectionError, TimeoutError
<p>def safe_get(client: Redis, key: str, max_retries=2):
for i in range(max_retries + 1):
try:
return client.get(key)
except (ConnectionError, TimeoutError) as e:
if i == max_retries:
raise e</p><h1>指数退避：100ms、300ms</h1><pre class="brush:php;toolbar:false;"> time.sleep(0.1 * (2 ** i))
# 强制刷新连接池中的当前连接
client.connection_pool.reset()
注意：client.connection_pool.reset() 会清空所有空闲连接，下次命令将新建连接——这是关键，否则重试仍可能命中断连句柄。
集群环境下重试不能简单换节点，得靠客户端重新计算 slot
Redis 集群靠 slot 分片，客户端必须自己维护 slots 映射表（通过 CLUSTER SLOTS 获取）。如果只是把失败请求转发给另一个随机节点，大概率收到 MOVED 或 ASK 响应，导致重试逻辑混乱。
正确做法是：重试前先触发一次 refresh_table_asap()（redis-py 提供），强制客户端拉取最新拓扑：
- 使用
RedisCluster实例（非普通Redis），它内置 slot 缓存和自动刷新机制 - 在重试逻辑中加入
client.nodes_manager.initialize()（新版redis-py-cluster）或client.refresh_node_slots() - 避免在高并发下频繁调用刷新接口，可加锁或限制最小刷新间隔（如 5 秒）
否则你重试了三次，每次连的都是旧拓扑里已下线的节点，越重试越错。
写命令（SET/DEL/HSET）原则上不自动重试，除非业务能保证幂等
连接中断后重发 SET foo bar，若原命令其实已成功执行，重试就会覆盖新值；INCR 类命令重复执行会导致计数错误。这是分布式系统中最容易被忽略的一致性陷阱。
可行方案只有两个：
- 业务层生成唯一请求 ID，写入时用
SET foo bar NX PX 60000+ 请求 ID 标记，重试前先查是否存在该标记 - 改用消息队列+最终一致性，把写操作转为异步任务，由消费者保障至少一次送达
别指望客户端 SDK 自动帮你搞定幂等——它没你的业务语义。
