分片后每个Redis节点必须独立配置持久化，RDB需统一save规则且隔离磁盘路径，AOF应全节点开启并设appendfsync everysec，避免部分节点未持久化导致数据丢失。
Redis 单实例扛不住大数据量时，直接上 RDB 或 AOF 持久化会卡死、阻塞、OOM，必须配合分片——但分片不是加机器就完事，持久化策略得跟着改。
分片后每个节点仍要独立配置持久化
分片只是把数据打散到多个 Redis 实例，每个实例仍是独立进程，redis.conf 中的 save、appendonly、appendfilename 等配置必须逐个设置，不能靠“主节点统一控制”。常见错误是只在第一个节点开 AOF，其余全关，导致故障恢复时部分数据永久丢失。
- 所有分片节点若需强一致性，应统一开启
appendonly yes，且建议用appendfsync everysec（兼顾性能与安全性） - 若用
RDB，各节点的save规则（如save 900 1）要一致，否则某些节点可能长期不落盘 - 注意磁盘路径隔离：每个节点的
dir和dbfilename必须不同，否则多个实例会互相覆盖dump.rdb
Redis Cluster 下持久化行为与单机不同
Redis Cluster 本身不改变持久化机制，但引入了主从复制和自动故障转移，这会让持久化效果变得“不可见”——比如主节点没开 AOF，但从节点开了，failover 后新主节点的数据就只来自 RDB 快照，中间写操作全丢。
- 集群中每个 master 节点都应启用
AOF，且从节点同步时默认复用主节点的持久化配置（但不会自动继承，需手动确认） -
cluster-enabled yes不会自动打开appendonly，这是两个正交配置项 - 迁移 slot 过程中，源 master 仍持续接收写请求，若此时它没开
AOF，而目标节点刚启动还没同步完，这部分增量就无法恢复
大 Key + AOF 导致 rewrite 阻塞与磁盘爆满
当某个分片里存在几 MB 的 Hash 或 Sorted Set，且启用了 AOF，bgrewriteaof 过程会频繁触发，每次重写都要遍历整个 key 内容，CPU 和磁盘 IO 飙升，甚至卡住整个实例。
- 用
redis-cli --bigkeys定期扫描各分片，发现 >100KB 的 key 就要拆分或换结构（比如用HSCAN分批读，而不是HGETALL） - 避免在
AOF开启时对大 key 做HSET全量更新；改用HMSET或分字段写入 - 给每个分片单独配
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，防止小节点因阈值过低频繁 rewrite
混合持久化（RDB+AOF）在分片环境的实际价值有限
Redis 4.0+ 支持 aof-use-rdb-preamble yes，即 AOF 文件开头嵌一个 RDB 快照。这在单机上能加速加载，但在分片场景下收益被稀释：
- 每个分片仍要独立执行
bgrewriteaof，无法跨节点合并快照 - 如果某分片数据量小、变更少，纯
RDB更轻量；反之高写入分片用纯AOF更安全 - 运维复杂度上升：需同时监控各节点的
RDB文件大小、AOF重写频率、磁盘剩余空间，三者不再解耦
真正关键的不是选哪种持久化，而是确保每个分片的落盘行为可预测、可监控、可回滚——尤其是那个正在承担 70% 流量却没开 AOF 的节点。
