Redis集群环境怎么排查连接超时_检查集群代理配置与负载均衡器策略-Redis-PHP中文网

redis集群连接超时多因客户端未正确连接节点或代理问题：直连主节点发跨槽命令、代理转发卡顿、k8s service轮询破坏粘性路由、健康检查误用http导致连接堆积、sdk未启用集群模式、超时重试策略不当等。

redis集群环境怎么排查连接超时_检查集群代理配置与负载均衡器策略

Redis集群连接超时，先看客户端连的是谁

很多“集群超时”根本不是集群的问题，而是客户端压根没连对节点——比如直连了某个主节点，却发了跨槽命令；或连了集群代理（如Twemproxy、Codis、Redis Proxy），但代理本身卡在转发环节。这时候 redis-cli -c 能连通，业务却报 Read timed out，大概率是代理层出了问题。

用 redis-cli -h proxy_ip -p 6379 ping 单独测代理是否响应正常，别只测后端 Redis 实例
检查代理日志里有没有 timeout、upstream connect timeout 或 no available backend 类错误
确认代理是否开启了集群感知（例如 Codis 的 product_name 配置、Twemproxy 不支持集群模式，强行用会出问题）
如果用了 Kubernetes Service 做负载均衡，注意默认是轮询，而 Redis 集群客户端要求“粘性路由”——某些请求必须落到特定 slot 对应的节点，代理不支持哈希路由就会反复重定向甚至超时

负载均衡器把健康检查当成真实请求打爆了连接数

常见陷阱：在 Nginx / ALB / SLB 上配置了 HTTP 健康检查，探测路径设成 /health，但后端是 Redis ——结果健康检查 TCP 握手后不发任何 Redis 协议数据，就挂在那里。Redis 把它当空闲连接，timeout 0 时永不释放，timeout 300 时等 5 分钟才断，大量半开连接堆积，connected_clients 快顶到 maxclients，新请求直接被拒绝。

查连接来源：redis-cli client list | grep -E 'addr=.*:|idle=' | awk -F'[ =]' '{print $2, $10}' | sort -k2 -n | tail -10，看是不是一堆相同 IP + 高 idle 值的连接
负载均衡器健康检查必须用 TCP 层（非 HTTP），且探测包要符合 Redis 协议：发 *1\r\n$4\r\nPING\r\n，收 +PONG\r\n
或者干脆关掉健康检查，改用集群自身 CLUSTER NODES + 客户端重试逻辑兜底（更推荐）

客户端 SDK 没走集群协议，却硬连集群地址

典型错误：用 Jedis 或旧版 Lettuce 直接 new Jedis("cluster-ip", 6379)，以为这是个普通 Redis 实例。实际上集群地址只是入口，真正命令要根据 key hash 到具体节点，而普通客户端不会解析 MOVED / ASK 重定向响应，直接卡死在第一次请求超时。

Jedis 必须用 JedisCluster 构造器，传入 nodes 列表，不能只传一个 host
Lettuce 推荐用 RedisClusterClient + ClusterTopologyRefreshOptions，避免拓扑缓存过期后仍往下线节点发请求
ioredis 要显式启用集群模式：new Redis.Cluster([{ host: '1.1.1.1', port: 6379 }])，否则默认当单机用
Spring Data Redis 从 2.6 开始默认启用集群自动发现，但若配置了 spring.redis.host 却没配 spring.redis.cluster.nodes，就会 fallback 成单机模式，导致超时

代理/客户端设置了超时，但没配重试和熔断

连接超时不是终点，而是信号。很多团队只调大 timeout=60000，结果慢请求把线程池堵死，下游全雪崩。真正的稳定性来自分层控制：网络层超时要短（1~3s），应用层重试要有退避，失败后要快速熔断。

客户端连接超时建议设为 2000ms，读写超时设为 1000ms（集群跨节点跳转本就多一次 round-trip）
ioredis 设置：retry_strategy 返回 false 表示不重试，socket.connectTimeout 和 socket.timeout 分开控制
不要依赖代理层重试（如 Envoy 的 retry_policy），Redis 命令幂等性差（INCR、LPUSH 重试会重复执行），重试逻辑必须由业务 SDK 控制，并区分命令类型
监控 redis_cluster_stats_keyspace_hits + redis_cluster_stats_keyspace_misses 突降，往往比连接超时更早暴露代理或拓扑异常