Redis集群平滑升级必须采用逐节点替换策略，因跨版本不兼容会导致槽位丢失或连接震荡；需先验证版本兼容性、统一配置参数、严格按加新—迁槽—下旧三步操作，并同步更新客户端拓扑发现机制。
Redis 集群平滑升级不能靠 CONFIG REWRITE 或热重启解决，必须走节点逐替策略——因为 Redis 集群协议不支持跨版本握手，6.x 与 7.x 的 CLUSTER NODES 格式、故障检测逻辑、ASK/MOVED 响应行为均有差异，强行混跑大概率触发槽位丢失或连接震荡。
确认新旧版本兼容边界
先查官方文档的「Cluster compatibility」章节：Redis 6.2+ 支持与 7.0 有限共存（仅限数据迁移阶段），但 6.0 与 7.2 无法直连；若当前是 5.0，必须先升到 6.2 再升 7.x。关键验证点：
-
redis-cli --cluster check在旧集群上运行，确保无fail状态节点和open slot - 新版本二进制启动后执行
redis-cli -p 6380 CLUSTER NODES，观察是否能解析旧节点的响应（字段顺序、空格分隔符是否一致） - 特别注意
redis.conf中cluster-require-full-coverage默认值变化（6.x 为yes，7.x 为no），不统一会导致部分节点拒绝服务
逐节点替换的操作顺序
不是简单停一个、起一个，而是「加新、迁槽、下旧」三步闭环。以替换主节点 192.168.1.10:7001 为例：
- 在新机器启动同配置的 Redis 7.x 实例，端口设为
7005，用redis-cli --cluster add-node 192.168.1.11:7005 192.168.1.10:7001加入集群 - 执行
redis-cli --cluster reshard 192.168.1.10:7001 --from <code>old-node-id--tonew-node-id--slots 16384 --yes 迁移全部槽位（注意：--from必须指定原主节点 ID，不能写 IP） - 等
CLUSTER NODES显示新节点状态为master且槽位数正确、旧节点变为fail后，再用redis-cli --cluster del-node 192.168.1.10:7001 <code>old-node-id下线
客户端连接层必须同步切流
很多团队只换服务端，却忽略客户端缓存的老节点地址。Jedis、Lettuce、StackExchange.Redis 均有默认重试机制，但会持续向已下线节点发请求，直到超时（默认 2s），造成毛刺。必须：
- 升级前检查客户端是否开启
refreshPeriod（Lettuce）或clusterRefreshInterval（Jedis），建议调小至 500ms - 替换节点期间，在应用侧通过
redis-cli -c -p 7001 CLUSTER SLOTS拿到最新拓扑，对比客户端本地缓存，发现不一致立即触发强制刷新 - 禁止使用静态 IP 列表初始化连接池，改用「任意一个活跃节点」自动发现模式（如 Lettuce 的
RedisURI.create("redis://192.168.1.10:7001")即可）
最易被忽略的是从节点升级时机——必须等对应主节点完成迁移并稳定 5 分钟以上再操作，否则主从复制链路可能因 RDB/AOF 兼容性问题中断；另外，所有节点的 maxmemory-policy 参数在 7.x 中新增了 noeviction 的子行为，若旧配置含 volatile-lru，需显式补全为 volatile-lru allkeys-lru 避免启动失败。
