Redis 6.0 升级至 7.0 不可“停一个、起一个”，必须验证 RDB 实际加载、闭环迁移集群节点、同步客户端拓扑刷新及 cluster-require-full-coverage 配置，否则将导致槽位丢失、连接震荡或数据错乱。
能平滑升级，但必须放弃“停一个、起一个”的直觉操作——Redis 6.0 和 7.0 之间存在集群握手协议、RDB 格式、AOF 结构三处不兼容点，任何跳步都会导致槽位丢失、连接震荡或数据加载失败。
先验证 RDB 文件能否被 Redis 7.0 正确加载
别信文档说的“6.x → 7.x 兼容”，得用你生产环境的真实 dump.rdb 文件实测。Redis 7.0 虽保留了对 6.x RDB 的解析能力，但只保证基础结构可读；若你的数据含 stream 消费组元数据、带过期时间的 listpack 小对象等细节，旧 RDB 可能加载后类型错乱或字段截断。
- 停掉当前 Redis 6.0 实例（确保无写入）
- 复制出真实的
dump.rdb和对应redis.conf - 用 Redis 7.0 二进制静默加载：
redis-server /path/to/redis.conf --dbfilename dump.rdb --dir /tmp/test-dir --port 0 --daemonize no - 重点看日志是否出现
DB loaded from disk，而非Failed trying to load the RDB format - 连接后执行
DBSIZE、KEYS *抽样、TYPE keyname和XINFO GROUPS streamname，比对与旧实例完全一致
集群节点替换必须走「加新—迁槽—下旧」闭环
Redis 集群不支持跨版本节点共存：6.0 和 7.0 的 CLUSTER NODES 响应格式不同（字段顺序、空格分隔）、故障检测超时逻辑变更、ASK/MOVED 重定向行为有差异。混跑超过 30 秒，就会触发部分 slot 标记为 fail，客户端持续收到 MOVED 重试，QPS 毛刺明显。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 新节点启动前，统一修改配置项：
cluster-require-full-coverage在 6.x 默认为yes，7.x 默认为no；不统一会导致新节点拒绝服务 - 加节点命令必须指向集群中任一存活节点，不是目标旧节点：
redis-cli --cluster add-node 192.168.1.11:7005 192.168.1.10:7001 - 迁移槽位时，
--from参数必须填旧节点的node id（从CLUSTER NODES输出里抄），不能写 IP+端口 - 等待新节点状态变为
master且CLUSTER NODES显示槽位数正确、旧节点状态为fail后，再执行redis-cli --cluster del-node 192.168.1.10:7001 <old-node-id>
客户端必须同步刷新拓扑缓存，不能靠自动重试扛
Jedis、Lettuce 等客户端默认会缓存集群拓扑 10～60 秒，并在连接失败后重试已下线节点，直到超时（常为 2s）。这意味着即使服务端节点已下线，客户端仍会持续向它发请求，造成 RT 毛刺和连接堆积。
- 升级前检查客户端是否启用拓扑刷新：Lettuce 看
refreshPeriod，Jedis 看clusterRefreshInterval；建议临时调小至500ms - 替换每个节点期间，在应用侧主动调用
redis-cli -c -p 7001 CLUSTER SLOTS获取最新拓扑，与客户端本地缓存比对，不一致立即触发强制刷新 - 禁止用静态 IP 列表初始化连接池（如
["192.168.1.10:7001", "192.168.1.10:7002"]），改用任意一个活跃节点自动发现：RedisURI.create("redis://192.168.1.10:7001")
AOF 升级后行为变化容易被忽略
Redis 7.0 默认启用 multi-part AOF（base.aof + incr_*.aof + manifest.aof），不再有传统意义上的 appendonly.aof 文件。如果你的应用或监控脚本硬编码依赖 appendonly.aof 文件名或大小判断，升级后会失效。
- 旧配置中
appendfilename "appendonly.aof"仍可存在，但实际写入的是base.aof和增量文件 -
CONFIG GET appendfilename返回值不变，但磁盘上看不到该文件；真正要监控的是manifest.aof是否更新、incr_*.aof文件数量是否异常增长 - 如果关闭了 RDB，仅靠 AOF 持久化，Redis 7.0 崩溃恢复时依赖
manifest.aof定位有效文件，该文件损坏即无法恢复
最易被跳过的动作是客户端拓扑刷新和 cluster-require-full-coverage 配置对齐——这两项不出错时一切正常，一出错就是集群不可用级别问题，且现象隐蔽：看起来连接都通，但部分 key 始终 MOVED 循环或返回空响应。
