Redis集群中AOF持久化必须为每个master节点单独启用并隔离IO路径，禁用共享磁盘与NFS，采用appendfsync everysec配专用NVMe盘及ionice优先级。
RDB在集群中默认不生效，只靠AOF重写+fsync策略无法真正保障数据持久性——必须配合节点级配置隔离与磁盘IO路径控制。
Redis集群节点不能共享AOF重写进程
AOF重写（bgrewriteaof）是单节点行为，集群中每个master节点独立执行。常见错误是误以为主从同步能“代劳”持久化：从节点即使开启AOF，也不会自动触发重写；若主节点AOF未启用，从节点即使开了也只记录自己收到的复制流（replica-serve-stale-data no时可能拒绝读），而非原始客户端写入。
- 必须为每个master节点单独配置
appendonly yes，且禁用appendonly no的从节点参与写操作 - 重写触发条件（如
auto-aof-rewrite-percentage 100）需按节点内存使用率单独评估，不能统一设阈值 - 重写期间子进程会fork，若节点内存超4GB，可能引发页表拷贝延迟，建议搭配
vm.overcommit_memory = 1内核参数
fsync策略直接决定AOF落地可靠性
appendfsync不是性能开关，而是数据安全分水岭。集群环境下更需警惕混合部署带来的IO干扰：
-
appendfsync always：每次写都落盘，但Redis单线程会卡在write()系统调用上——集群中若多个节点共用一块SATA盘，IOPS瓶颈会导致整体写入延迟飙升 -
appendfsync everysec（默认）：折中选择，但要注意Linux脏页回写机制（vm.dirty_ratio）可能让实际刷盘延迟超过1秒 -
appendfsync no：交由OS调度，等同于放弃AOF持久性承诺，集群脑裂时极易丢失最后几秒数据
生产环境唯一可接受的是everysec，但必须绑定专用NVMe盘，并通过ionice -c 1 -n 0提升IO优先级。
磁盘IO路径必须与Redis实例物理隔离
集群节点若混用同一块磁盘，AOF日志、RDB快照、系统日志三者争抢IO队列，bgrewriteaof期间子进程大量顺序写会阻塞主线程的fsync调用。实测显示：4节点共用一块7200rpm SATA盘时，AOF重写耗时增加3.2倍，且出现Failed to rewrite the AOF: No space left on device错误（因临时文件+原AOF同时占用空间）。
- 每个Redis实例应独占一块SSD/NVMe设备，挂载路径如
/data/redis-node-7001 - AOF文件路径（
dir）和重写临时文件路径（appendfilename）必须在同一挂载点，避免跨设备rename失败 - 禁用ext4的
journal=ordered模式，改用data=writeback（需确保断电保护UPS）
最容易被忽略的是AOF重写完成后的原子替换动作——它依赖rename()系统调用的原子性，而某些网络文件系统（如NFSv3）不保证这点，集群中一旦某个节点挂载了NFS存储，bgrewriteaof成功后可能无法生效，导致持续使用旧AOF文件回放。
