redis数据一致性仅指自身重启后准确还原内存状态，rdb为定时快照、aof为命令日志，二者均不保障跨系统一致性；rdb丢失两次快照间数据，aof最多丢1秒（everysec模式），混合模式下启动优先加载aof。
Redis 本身不负责与 MySQL 或其他外部数据库的一致性，它的“数据一致性”仅指自身重启后能否准确还原内存状态——RDB 和 AOF 都只为这个目标服务，不是跨系统同步方案。
RDB 快照触发时机与丢失窗口
RDB 是定时全量快照，save 和 bgsave 都只保存执行时刻的内存副本。这意味着两次快照之间的写操作在宕机时会全部丢失。
-
save 60 10000表示 60 秒内有 10000 次写就触发一次快照，但若第 9999 次写完后立刻断电，这 9999 条数据全丢 - 手动执行
bgsave虽不阻塞主线程，但快照内容仍是 fork 时刻的内存快照，之后的写入不包含在本次 RDB 中 - RDB 文件生成期间（尤其大内存实例），子进程 fork 开销可能引发短时延迟，但不影响主线程写入逻辑
AOF 日志重放的精度与性能权衡
AOF 记录的是每条写命令，重启时靠重放日志恢复状态，理论上比 RDB 更少丢数据，但实际取决于 appendfsync 策略。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
appendfsync always：每次写都 fsync 到磁盘，最安全但性能最差，仍可能因内核缓存未刷盘而丢少量数据 -
appendfsync everysec（默认）：每秒刷盘一次，最多丢 1 秒数据；高并发下可能堆积多条命令，崩溃时丢失的是这一秒内所有未刷盘命令 -
appendfsync no：交由操作系统决定，丢数据风险显著升高，不建议生产使用 - AOF 重写（
bgrewriteaof）会压缩日志体积，但重写过程本身不保证原子性，若中途失败，旧 AOF 文件仍可用
RDB+AOF 混合使用时的真实行为
Redis 4.0+ 支持同时开启 RDB 和 AOF，但启动时**只加载 AOF 文件**——RDB 在这种配置下仅作为备份或人工恢复手段，不参与自动恢复流程。
- 若 AOF 文件存在且完整，Redis 启动时忽略
dump.rdb，哪怕它更新时间更晚 - 若 AOF 文件损坏或被禁用，才会 fallback 到加载 RDB 文件
- AOF 重写生成的新文件，会覆盖旧 AOF，但重写完成前旧文件持续追加，确保不丢中间状态
- 注意：
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size控制重写触发条件，设置过低会导致频繁重写、磁盘 IO 压力增大
真正容易被忽略的是：无论 RDB 还是 AOF，它们都只解决 Redis 单实例本地恢复问题。一旦涉及 MySQL、Elasticsearch 或其他系统，所谓“一致性”必须由业务层或中间件（如 Canal、Bifrost）保障，Redis 自身没有任何跨存储协调能力。
