Redis持久化机制如何保障数据一致性？

Redis数据一致性仅指自身重启后准确还原内存状态，RDB为定时快照、AOF为命令日志，二者均不保障跨系统一致性；RDB丢失两次快照间数据，AOF最多丢1秒（everysec模式），混合模式下启动优先加载AOF。

Redis 本身不负责与 MySQL 或其他外部数据库的一致性，它的“数据一致性”仅指自身重启后能否准确还原内存状态——RDB 和 AOF 都只为这个目标服务，不是跨系统同步方案。

RDB 快照触发时机与丢失窗口

RDB 是定时全量快照，save 和 bgsave 都只保存执行时刻的内存副本。这意味着两次快照之间的写操作在宕机时会全部丢失。

1. save 60 10000 表示 60 秒内有 10000 次写就触发一次快照，但若第 9999 次写完后立刻断电，这 9999 条数据全丢
2. 手动执行 bgsave 虽不阻塞主线程，但快照内容仍是 fork 时刻的内存快照，之后的写入不包含在本次 RDB 中
3. RDB 文件生成期间（尤其大内存实例），子进程 fork 开销可能引发短时延迟，但不影响主线程写入逻辑

AOF 日志重放的精度与性能权衡

AOF 记录的是每条写命令，重启时靠重放日志恢复状态，理论上比 RDB 更少丢数据，但实际取决于 appendfsync 策略。

1. appendfsync always：每次写都 fsync 到磁盘，最安全但性能最差，仍可能因内核缓存未刷盘而丢少量数据
2. appendfsync everysec（默认）：每秒刷盘一次，最多丢 1 秒数据；高并发下可能堆积多条命令，崩溃时丢失的是这一秒内所有未刷盘命令
3. appendfsync no：交由操作系统决定，丢数据风险显著升高，不建议生产使用
4. AOF 重写（bgrewriteaof）会压缩日志体积，但重写过程本身不保证原子性，若中途失败，旧 AOF 文件仍可用

RDB+AOF 混合使用时的真实行为

Redis 4.0+ 支持同时开启 RDB 和 AOF，但启动时只加载 AOF 文件——RDB 在这种配置下仅作为备份或人工恢复手段，不参与自动恢复流程。

1. 若 AOF 文件存在且完整，Redis 启动时忽略 dump.rdb，哪怕它更新时间更晚
2. 若 AOF 文件损坏或被禁用，才会 fallback 到加载 RDB 文件
3. AOF 重写生成的新文件，会覆盖旧 AOF，但重写完成前旧文件持续追加，确保不丢中间状态
4. 注意：auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 控制重写触发条件，设置过低会导致频繁重写、磁盘 IO 压力增大

真正容易被忽略的是：无论 RDB 还是 AOF，它们都只解决 Redis 单实例本地恢复问题。一旦涉及 MySQL、Elasticsearch 或其他系统，所谓“一致性”必须由业务层或中间件（如 Canal、Bifrost）保障，Redis 自身没有任何跨存储协调能力。