不能直接复用默认RDB配置，因原生save触发的全量快照无法支撑异地多活所需的可靠增量同步，易致同步退化、延迟放大或数据丢失；必须关闭自动RDB（save ""），启用AOF（appendonly yes + appendfsync everysec），并配合同步工具过滤与文件隔离机制。
异地多活场景下，Redis 的持久化不能照搬单机房配置——RDB 或 AOF 单独启用，大概率导致同步延迟放大、数据回环、或 failover 时丢失跨地域已同步但未落盘的命令。必须把持久化策略和同步链路耦合设计。
为什么不能直接复用默认 RDB 配置
原生 save 触发的 RDB 是全量快照，两次快照间隔内所有写操作都只存在内存；而异地多活依赖增量同步（如监听 repl_backlog 或 AOF 日志），一旦主节点崩溃且未及时触发 RDB，同步工具可能因缺失起点偏移而退化为全量重传，跨地域下耗时数分钟甚至更久。
更危险的是：若配置了 save 900 1 这类低频条件，在低流量时段可能数小时不出 RDB 文件，此时若同步中断又恢复，redis-port 或 RedisShake 可能因无可靠起始点而丢弃部分增量。
- 必须关闭自动 RDB（
save ""），改由外部同步工具控制 checkpoint 时机 - 每个机房的 Redis 实例应禁用
stop-writes-on-bgsave-error yes，避免 RDB 失败阻塞写入 - 如需 RDB 用于灾备归档，应单独定时调用
SAVE命令（非BGSAVE），并确保该操作不干扰同步组件的复制流读取
必须开启 AOF 并严格配置 appendfsync
AOF 是异地多活中唯一可靠的增量来源。同步工具（如 RedisShake）基本都依赖解析 AOF 文件或 AOF rewrite 后的临时文件来捕获命令；没有 AOF，就等于切断了同步的“血液供应”。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须设置
appendonly yes，且禁用auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，防止 rewrite 过程中产生不可预测的文件切换 -
appendfsync必须设为everysec：设为always会显著拖慢写入吞吐（尤其跨地域写多场景）；设为no则失去同步基础——哪怕只丢 1 秒日志，也可能造成两个机房对同一 key 的 SET 冲突无法识别 - 务必配置
aof-rewrite-incremental-fsync yes，降低 rewrite 期间 I/O 尖峰对同步延迟的影响
如何避免 AOF 日志被同步工具误读或回环
双向同步时，AOF 文件本身不带来源标记，DC-A 写入的命令经同步到达 DC-B 后，若 DC-B 的 AOF 又被同步回 DC-A，就会形成无限循环。这不是理论风险，而是线上高频事故。
- 同步工具必须启用过滤能力：
--filter-db按数据库号隔离，--filter-key "dc_a:*"排除本机房标记的 key（前提是业务写入时主动加前缀） - Redis 配置需配合：设置
replica-announce-ip和replica-announce-port，让同步工具能区分主从角色；再配合 IP 白名单，使 DC-B 的同步进程只读取 DC-A 的 master 节点，不读自身 replica 的 AOF - 禁止在从机房开启
appendfilename与主机房相同——例如 DC-A 用appendfilename "appendonly.aof"，DC-B 应改为"appendonly_dc_b.aof"，避免文件名冲突导致日志错读
真正难的不是选 RDB 还是 AOF，而是让持久化行为与同步边界完全对齐：AOF 不只是保命手段，它就是同步协议的数据源；任何绕过 AOF 的写路径（比如直连 replica 写入、或用 DEBUG RELOAD 强制加载 RDB）都会撕裂这个契约。上线前必须用真实断网+kill -9 模拟验证：恢复后两端数据是否可收敛、有无静默丢失。
