上一节我们极其硬核地扒开了 RDB 的底层 fork 和 COW 机制，明白了它是如何巧妙地利用操作系统特性来做“无感”快照的。
但是，RDB 最大的软肋也已经暴露无遗：两次快照之间的数据，在宕机时会彻底丢失。 如果你的业务是电商订单、金融支付，哪怕丢失 5 分钟的数据都是毁灭性的灾难。
为了解决这个“丢数据”的致命痛点，Redis 祭出了它的第二把绝世好剑——AOF (Append Only File) 。
📚 高级篇 04. Redis 持久化 - AOF 原理与刷盘策略
一、 核心认知：什么是 AOF？
AOF (Append Only File) ，直译为追加文件。
如果说 RDB 是给数据“拍静态照片”，那么 AOF 就是给 Redis 的动作“录像”。
AOF 的核心思想是：Redis 处理的每一个写命令（增、删、改），都会被记录在一个单独的日志文件（appendonly.aof）中。
当 Redis 重启时，它只需要把这个 AOF 文件里的命令从头到尾重新执行一遍，就能完美恢复出宕机前的一模一样的数据。
二、 开启 AOF (修改 redis.conf)
AOF 在 Redis 中默认是关闭的。我们需要修改配置文件 redis.conf 来开启它：
Properties
# 1. 开启 AOF 功能 (默认是 no，改成 yes)
appendonly yes
# 2. 指定 AOF 文件的名称 (默认就是这个)
appendfilename "appendonly.aof"
# 3. 指定文件保存的路径 (和 RDB 共用 dir 配置)
dir ./
重启 Redis 后，你随便执行几条 set 命令，打开 Redis 的运行目录，就会看到多了一个 appendonly.aof 文件。如果你用文本编辑器打开它，会发现里面记录的都是类似 *3\r\n$3\r\nset\r\n$4\r\nname\r\n$4\r\njack\r\n 这样的 Redis 协议格式的原始命令。
三、 面试必考点：AOF 的三种刷盘策略 (fsync)
AOF 记录命令时，并不是直接写进磁盘的。
现代操作系统的机制是：程序写文件时，先写到操作系统的 Page Cache（内存缓冲区） 里，然后操作系统再根据自己的节奏，把缓冲区的数据真正写到物理磁盘上（这个动作叫 fsync 刷盘）。
问题来了：如果在写进缓冲区后，还没来得及刷盘，服务器突然断电了怎么办？ 数据还是会丢！
因此，Redis 给了我们三种控制刷盘时机的策略（在 redis.conf 中配置 appendfsync）：
| 刷盘策略 (appendfsync) | 触发时机 | 优点 | 缺点 (致命伤) | 适用场景 |
|---|---|---|---|---|
always (同步刷盘) | 每次执行写命令，立刻强行刷入磁盘。 | 绝对不丢数据 (可靠性最高)。 | 极度拖慢性能！Redis 退化成磁盘数据库，QPS 暴跌。 | 几乎不用（除非是极其核心的账本系统）。 |
everysec (每秒刷盘) | 写命令先放入缓冲区，后台线程每隔 1 秒执行一次刷盘。 | 性能极高，与关闭 AOF 几乎无异。 | 最多丢失 1 秒 的数据。 | 默认配置，也是企业级黄金折中方案！ |
no (交由系统盘) | 写命令放入缓冲区，Redis 不管了，由操作系统决定何时刷盘。 | 性能最高。 | 无法控制数据丢失量，可能丢失几十秒甚至更多的数据。 | 不推荐使用。 |
🌟 面试话术：
“在生产环境中，我们通常毫不犹豫地选择
everysec策略。因为它在‘极致的高并发性能’和‘极高的数据安全性’之间找到了最完美的平衡点。哪怕遇到百年不遇的机房断电，最多也只损失 1 秒钟的数据，这在 99% 的业务场景中都是完全可以接受的。”
