Redis 7.0主从复制中真正影响稳定性的核心配置是replica-serve-stale-data行为、TTL绝对时间复制、Multi-Part AOF的manifest依赖及ACLv2权限授权，任一疏忽均会导致数据不一致或服务不可用。
Redis 7.0 主从复制配置里，真正影响线上稳定性和运维习惯的，是 replica-serve-stale-data 行为变更、TTL 复制方式调整、以及多 AOF 文件对故障恢复路径的隐性改变——不是所有“新特性”都值得配，但这几个不留意会直接导致数据不一致或服务不可用。
replica-serve-stale-data=no 时 PING 不再返回，别误判从节点宕机
在 Redis 7.0 中，当配置 replica-serve-stale-data no（即从节点拒绝提供过期/未同步数据），且主节点已不可达时，PING 命令将**直接超时或无响应**，而不是返回 NOAUTH 或 LOADING 等明确错误码。
- 这是为了防止客户端把“无法提供新鲜数据”的从节点当作可用节点路由读请求
- 监控脚本若只依赖
PING成功就认为节点健康，会漏掉这种“静默不可用”状态 - 正确做法是搭配
INFO replication检查master_link_status:down和master_last_io_seconds_ago是否超阈值
TTL 总是按绝对毫秒时间复制，不再推算相对过期时间
Redis 7.0 起，主节点写入 key 时设置的 TTL，会以当前时间戳 + TTL 计算出的**绝对毫秒时间**，原样复制到从节点；旧版本（≤6.x）是复制相对 TTL 值，由从节点本地计算过期时间。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 这意味着：主从服务器系统时间偏差 >1 秒时，从节点 key 过期行为会与主节点不一致
- 如果你依赖
EXPIREAT或PEXPIRE的精确时间语义（比如延时队列、缓存穿透防护），必须确保主从 NTP 同步精度 ≤500ms - 检查方式：
redis-cli -h $slave info | grep expired_keys对比主从该指标增长是否同步
Multi-Part AOF 改变故障恢复流程，manifest 文件必须完整
Redis 7.0 默认启用 Multi-Part AOF，AOF 恢复不再只读一个 appendonly.aof，而是依赖 appendonly.aof.manifest 清单文件协调 base + incr 文件加载顺序。
- 如果手动清理 AOF 文件（比如用
redis-cli BGREWRITEAOF后删旧文件），但没同步更新 manifest，Redis 启动时可能跳过部分 incr 文件，造成数据丢失 - 清单文件本身不参与 AOF rewrite，但会被
CONFIG REWRITE自动维护；若用外部脚本管理 AOF 目录，必须调用CONFIG SET appenddirname触发 manifest 重写 - 上线前务必验证：
cat appendonlydir/appendonly.aof.manifest中列出的 base/incr 文件物理存在且可读
ACLv2 权限控制影响复制连接，replica 用户需显式授权
Redis 7.0 ACLv2 默认不赋予 replica 用户任何权限，而旧版 ACL（v1）隐式允许复制连接。若你启用了 ACL 且配置了 requirepass，从节点连接会因权限不足被拒绝。
- 必须给 replica 用户至少授予：
on,replconf,psync,sync,get,info - 典型命令：
ACL SETUSER replica on >mypass ~* +replconf +psync +sync +get +info - 注意：
~*是 key pattern，如果主节点有敏感 key，应限制为~myapp:*等具体前缀
真正要盯住的不是“支持多少新命令”，而是这些配置项背后的时间语义、文件依赖和权限边界——它们不会报错，但会在主从切换、时间漂移或目录清理后悄然破坏一致性。
