redis集群网络分区时响应延迟飙升实为节点失联导致降级或拒绝写入，需先执行cluster nodes查fail/noaddr状态、cluster info查cluster_state:fail或cluster_slots_assigned:0，再排查底层网络连通性。
Redis集群出现网络分区时，响应延迟飙升甚至超时
网络分区不是“Redis变慢”，而是部分节点失联后，集群自动降级为只读或拒绝写入——你看到的“慢”，其实是客户端重试、重定向、超时等待叠加的结果。关键不是优化命令，而是确认分区是否真实发生，并快速干预。
先用 redis-cli -c -h {host} -p {port} 连任意节点，执行 CLUSTER NODES，观察输出中是否有大量节点状态为 fail 或 noaddr；再检查 CLUSTER INFO 中的 cluster_state:fail 或 cluster_slots_assigned:0 —— 这两类输出是分区最直接的证据。
- 不要依赖单个节点的
INFO replication判断主从连通性，它只反映本节点视角 - 防火墙、安全组、云厂商SLB健康检查失败都可能触发误判，需同步排查底层网络连通性（如 telnet、tcping）
- 若使用 Redis Cluster，且分片数少于 16384 槽位被分配，集群会直接拒绝写操作，此时
SET类命令会返回(error) CLUSTERDOWN
客户端持续收到 MOVED/ASK 重定向，但请求始终失败
这不是客户端配置问题，而是网络分区后槽位映射混乱的典型表现：客户端缓存了旧的 slot → node 映射，而实际负责该 slot 的节点已不可达，导致每次重定向都跳向一个“假死”节点。
解决办法不是刷新客户端缓存，而是强制重建路由表：
- Java 客户端（如 JedisCluster）调用
client.flushSlotCache()或重启连接池 - Python redis-py-cluster 需显式调用
redis_cluster.connection_pool.nodes.reset() - 所有客户端都应启用
retryAttempts+retryInterval（建议 ≥3 次，间隔 ≥50ms），避免在分区未恢复时疯狂重试
注意：ASKING 命令仅用于迁移中的临时重定向，不能替代 slot 表刷新；强行发送 ASKING 到错误节点只会返回 MOVED，形成循环。
从节点大量处于 wait_bgsave 状态，主节点 CPU 持续 100%
这往往不是磁盘 IO 问题，而是网络分区期间主节点反复尝试与失联从节点握手，触发频繁 fork 和心跳超时处理，消耗主线程资源。此时 INFO replication 里 connected_slaves 数值跳变、master_repl_offset 停滞，都是佐证。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
应急操作优先级如下：
- 立即在主节点执行
CONFIG SET repl-timeout 5（默认 60 秒），缩短心跳超时判定时间 - 若确认某从节点永久失联，用
CLUSTER FORGET {node-id}主动剔除（需在所有可达节点上执行） - 禁止在分区未修复前执行
CLUSTER RESET或重启节点，否则可能丢失槽位元数据
分区恢复后，Redis 不会自动重新握手——必须手动触发 CLUSTER MEET 或等待心跳自然重建，但前提是双方端口互通且防火墙放行 cluster bus 端口（默认比服务端口大 10000，如 6379 → 16379）。
业务请求成功率骤降，但监控显示 Redis 实例 CPU/内存正常
这是最容易被忽略的陷阱：性能指标“好看”，不代表可用性正常。网络分区下，instantaneous_ops_per_sec 可能暴跌，rejected_connections 上升，而 used_memory 和 cpu_sys 却无明显变化。
真正该盯紧的指标只有三个：
-
cluster_stats_messages_sent与cluster_stats_messages_received差值持续扩大 → 节点间通信中断 -
connected_clients突增后又陡降 → 客户端因重试/超时批量断连 -
evicted_keys在分区期间非预期上涨 → 内存淘汰策略被异常触发（如主节点误判从节点失联为负载过高）
别只看 Grafana 里的曲线，直接在每台 Redis 服务器上跑 redis-cli --latency -h 127.0.0.1 —— 如果本地延迟正常（100ms，基本锁定是网络层问题，而非 Redis 自身。
