redis 7.0未引入“分片全局状态”，而是优化元数据同步效率：通过新增update消息类型加速slot变更传播、默认启用asking自动重试、cluster nodes增加stable标志位、提升gossip消息压缩率，核心元数据仍为myself、nodes列表、slots分配、epoch和replication-offset。
Redis 7.0 并没有引入“分片全局状态”这个新概念——它只是强化了 Cluster 模式下元数据同步的粒度和效率，核心仍是 slot 映射表 + gossip 协议，但优化了变更传播路径和客户端重定向行为。
Redis Cluster 元数据到底包含哪些关键字段
集群中每个节点维护的元数据不是抽象的“全局状态”，而是具体可枚举的几项：myself 节点身份、nodes 列表（含 IP/端口/role/state）、slots 分配（如 0-5460 → 192.168.1.10:7000）、epoch（用于故障转移选主）、replication-offset（复制进度）。这些数据通过 ping/pong 消息在 gossip 中周期性广播。7.0 之前的问题是：slot 变更（比如 CLUSTER ADDSLOTS 或故障转移后）必须等全量 ping 周期（默认 100ms）才能被其他节点感知，导致短暂的 MOVED 错误或路由错误。
Redis 7.0 的元数据优化实际改了什么
重点不是加新字段，而是让 slot 变更更快、更准地触达客户端：
- 引入
UPDATE消息类型：当节点发现某个 slot 所属 master 发生变化（例如从 A 切到 B），它会主动向邻居发送UPDATE消息，而不是等下一个ping； - 客户端首次收到
MOVED后，若紧接着又收到同 key 的ASK，7.0 默认启用ASKING自动重试（旧版本需显式发ASKING）； -
CLUSTER NODES输出新增stable标志位，表示该节点当前 slot 映射已收敛，可用于判断集群是否完成重平衡； - gossip 消息体压缩率提升，相同带宽下能携带更多节点元数据，减少多跳传播延迟。
为什么你写的客户端代码在 7.0 下仍可能出错
常见误区是认为“7.0 自动解决所有路由问题”，其实不然：
- 跨槽操作（如
MGET key1 key2）依然被拒绝，只要两个 key 落在不同 slot，就报CROSSSLOT错误，跟版本无关； - 手动执行
CLUSTER SETSLOT ... MIGRATING时，如果客户端没正确处理ASK响应，7.0 不会帮你兜底； - 使用老版 Lettuce（UPDATE 消息解析逻辑，导致本地 slot 缓存长期不更新；
-
redis-cli --cluster工具在 7.0 中默认开启--cluster-use-empty-masters，但你的运维脚本若硬编码了旧参数，可能意外跳过空 master 节点校验。
真正容易被忽略的是：slot 映射收敛不是瞬时的，哪怕用了 7.0，节点间传播仍存在毫秒级窗口；业务里对 MOVED/ASK 的重试逻辑不能省，也不能只试一次。
