必须将cluster-node-timeout设为至少45000ms且所有节点一致，因跨机房rtt达20–80ms，单次往返若接近timeout的1/3（约5秒）易误判下线，导致slot迁移中断或集群卡在fail?状态。
cluster-node-timeout设太小会直接触发误判下线
跨机房 RTT 普遍在 20–80ms，Redis 默认 cluster-node-timeout 是 15000（15秒），看似宽松，但实际非常危险。心跳包往返一次若接近 timeout 的 1/3（即约 5 秒），就可能被判定为节点失联——尤其在 slot 迁移期间高频发包，极易中断迁移、卡在 fail? 状态。
必须统一将所有节点的 cluster-node-timeout 设为至少 45000，生产建议 60000。这不是“调大一点”，而是硬性前提：
- 所有节点
redis.conf中必须显式配置，不能只改部分节点 - 修改后逐个执行
redis-cli -h node-ip config rewrite+config reload，不要依赖重启 - 用
redis-cli --cluster check验证各节点看到的值是否一致，避免配置漂移
读请求不会自动落到本地从节点
加了本机房从节点 ≠ 读延迟下降。Jedis 默认直连 master；Lettuce 不显式设置 ReadFrom.REPLICA_PREFERRED 就不走 replica；ioredis 不配 scaleReads: 'slave' 同样无效。跨机房场景下，95% 以上读流量仍打向远端主节点。
必须按客户端类型显式路由：
- Jedis：不用默认构造器，改用
new JedisPool(..., localSlaveHost, localSlavePort)显式指向本机房从节点 - Lettuce：初始化时传
ClientOptions.builder().readFrom(ReadFrom.REPLICA_PREFERRED) - ioredis：启用
enableReadyCheck: true和scaleReads: 'slave'后，还需结合 DNS 或服务发现过滤出本机房 IP 段，否则可能选到异地 slave
主从复制链路本身抗抖动能力极弱
跨机房带宽低、丢包率高，master_repl_offset 和 slave_repl_offset 差值很容易拉大，轻则读旧数据，重则从节点静默降级为只读，客户端写入时报错 READONLY You can't write against a read only replica。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键参数必须调整：
-
repl-backlog-size至少设为1024mb（默认仅 1mb），防止网络抖动触发全量同步 -
repl-backlog-ttl从默认3600改为14400，延长缓冲区存活时间 -
repl-ping-replica-period从 10s 改为 5s，加快主节点对从节点失联的感知 - 启用
repl-diskless-sync yes（需确认双方 Redis ≥ 3.0），减少 RDB 文件落地开销
别指望 proxy 层自动识别机房拓扑
Twemproxy、Codis、CacheCloud 这类集群代理，本身不识别机房信息，也不做就近路由。它们只做简单哈希或一致性哈希转发，请求照样可能被转到异地节点，延迟照旧，故障隔离也无从谈起。
真正可控的方式只有两个：
- 客户端直连 + 显式分机房连接池（如 JedisPool 分两组，一组连本地 master，一组连本地 slave）
- 在服务发现层（如 Nacos、Consul）按标签隔离机房，由业务代码或 SDK 根据本地 zone 选择对应节点列表
监控上要盯紧 keyspace_hits 和 rejected_connections：如果异地读占比突然上升，大概率是本地从节点已静默故障，但还没被集群或客户端感知到。
