1. 课程导入与全景认知

Redis 以内存为工作介质，读写延迟通常在微秒到毫秒级，这是它被广泛用于缓存、会话、排行榜、计数器、消息队列和分布式锁的根本原因。但内存有一个无法回避的物理事实：进程退出、主机断电、容器被调度重建，内存中的数据就会消失。持久化要解决的，正是“内存易失”与“业务需要数据长期存在”之间的矛盾。它不是给 Redis 加一个可有可无的备份功能，而是决定 Redis 能否承担关键数据职责的分界线。

理解持久化的价值，可以从三个真实场景切入。第一类是缓存场景：Redis 中存放的是数据库数据的副本，丢失后可以回源重建，此时持久化的意义是降低回源压力、缩短恢复时间，而不是保证数据不丢。第二类是会话与状态场景：用户登录态、购物车、分布式锁的持有者等信息只存在于 Redis，一旦丢失，用户需要重新登录、锁可能被重复获取，持久化直接关系到业务连续性。第三类是“Redis 作为主存储”的场景：例如用 Redis 存储实时计数、去重集合、时序采样点，这些数据没有上游数据库可以回源，持久化就是唯一的数据安全底线。三类场景对 RPO（可容忍丢失的数据量）和 RTO（可容忍的恢复时间）要求完全不同，这也决定了后面章节中 RDB、AOF、混合持久化以及主从、哨兵、集群等方案的选择逻辑。

Redis 的持久化体系并不是单一机制，而是由若干层能力叠加而成。最底层是两种基础持久化方式：RDB 以某一时刻的内存快照为单位落盘，文件紧凑、恢复快，但两次快照之间的数据会丢失；AOF 以追加写命令日志的方式记录每一次写操作，丢失窗口小，但文件更大、恢复时需要重放命令。Redis 4.0 之后引入的混合持久化，把 RDB 的全量快照与 AOF 的增量命令结合在同一个文件中，兼顾恢复速度与数据完整性。再往上是复制与高可用：主从复制把数据同步到多个节点，哨兵负责故障发现与自动切换，集群在分片的同时提供副本冗余。最外层则是运维与恢复体系：备份策略、文件校验、恢复演练、监控告警和故障复盘。这四层共同构成“数据恢复体系”，持久化只是其中的地基。

把这张全景图落到工程实践，需要先建立几个关键概念。RPO 指故障发生时最多能接受丢失多少数据，通常用时间衡量，例如“最多丢 1 秒”；RTO 指从故障发生到服务恢复可用的时间，例如“5 分钟内恢复”。RDB 的 RPO 取决于快照间隔，若每 5 分钟做一次快照，最坏情况会丢近 5 分钟数据；AOF 的 RPO 取决于 appendfsync 策略，everysec 通常最多丢约 1 秒，always 理论上不丢但性能开销显著。RTO 则取决于文件大小、磁盘 IO、网络带宽和恢复方式：一个 10 GB 的 RDB 文件在本地 SSD 上加载可能只需几十秒，而重放同等数据量的 AOF 可能要几分钟。这些量级关系是后续做方案选型时最常用的判断依据。

学习路径上，本课程按“原理—配置—验证—排障—架构”推进。先讲清 RDB 的触发方式（save、bgsave、自动触发）与 fork 写时复制机制，再讲 AOF 的写入、缓冲、刷盘与重写流程，然后进入混合持久化与恢复流程，包括文件加载顺序、损坏文件处理、redis-check-rdb 与 redis-check-aof 的使用。之后进入复制、哨兵与集群中的持久化协同问题，例如主从切换时如何选择最新数据的副本、脑裂场景下如何避免数据被覆盖。最后通过故障演练与复盘，把知识转化为可执行的恢复能力。

实战目标可以具体化为四项能力：第一，能根据业务 RPO/RTO 要求，为不同实例选择并配置合适的持久化组合；第二，能读懂 RDB 与 AOF 文件的基本结构，判断文件是否完整、是否可恢复；第三，能独立完成一次从备份文件到新实例的数据恢复，并验证数据一致性；第四，能在主从切换、磁盘写满、AOF 损坏等异常场景下定位问题并给出处置方案。这四项能力贯穿全部 30 章，也是每章练习与复盘的落脚点。