结论：appendfsync everysec + aof-use-rdb-preamble yes 是2026年生产环境最普适的平衡点，兼顾性能与RPO；everysec避免always的吞吐断崖，混合模式使重启秒级加载RDB段并重放1秒内增量，RPO稳定≤1s，且规避纯RDB快照间隔过长风险。
直接说结论：appendfsync everysec + aof-use-rdb-preamble yes 是当前（2026年）生产环境最普适的平衡点，既避免了 always 的吞吐断崖，又比纯 RDB 显著收窄 RPO。
为什么 appendfsync always 不该默认开启
它名义上“每条命令都落盘”，但实际存在三处不可控断层：进程可能在 write() 后、fsync() 前被 SIGKILL 终止；fsync() 成功后数据仍可能卡在 Linux page cache 或 SSD 写缓存里；硬盘控制器若未禁用写缓存（比如没跑过 hdparm -W0 /dev/sda），数据还在设备 RAM 中。实测中，SET 吞吐会从 everysec 下的 58k+ req/s 跌到约 58k，性能损失 5–10 倍，却换不来真正的 RPO=0。
everysec 的真实行为与风险边界
它不是严格按钟表每秒刷一次，而是由 Redis 主循环定时器驱动，因此受主线程状态影响明显：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 若主线程卡住（比如执行
KEYS *、序列化超大 value、或 GC 停顿），AOF 刷盘可能延迟数秒 -
bgrewriteaof运行期间，新命令仍追加到旧 AOF 文件，everysec对这部分依然生效 - 磁盘 I/O 延迟突增时（如 RAID 卡电池学习、SSD GC），Redis 默认会临时降级为
always刷盘——这个行为由no-appendfsync-on-rewrite no控制，别误以为关了它就“稳了”
混合持久化不是锦上添花，而是关键补位
开启 aof-use-rdb-preamble yes 后，AOF 文件开头是 RDB 格式的全量快照，后面是增量命令。重启时先加载 RDB 段（快），再重放 AOF 增量段（准）。这解决了两个硬伤：
- 纯 AOF 恢复慢：重放几百万条命令可能耗时数分钟；混合模式下，90% 数据靠 RDB 段秒级载入
- 纯 RDB RPO 太大：64GB 实例若按默认
save 60 10000，可能每分钟才触发一次快照；混合模式下，RPO 由 AOF 增量段决定，稳定在 1 秒内 - 注意：混合模式不降低
bgrewriteaof开销，它只是把 RDB 快照塞进 AOF 文件，而非跳过重写
真正容易被忽略的是：混合模式下，redis-check-aof 工具无法校验带 RDB preamble 的文件，必须用 redis-check-rdb 配合解析逻辑——这点在灾备演练时经常翻车。
