Redis AOF 持久化
AOF 持久化简介
除了 RDB 持久化之外，Redis 还提供了 AOF（Append Only File，即只允许追加不允许改写的文件）持久化。
与 RDB 持久化通过保存数据库中的键值对来记录数据库状态不同，AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库状态
开启 AOF 持久化功能
开启 AOF 持久化功能，需要修改 redis.conf 配置文件，如下：
[root@node-01 redis-5.0.9]# vim redis.conf
appendonly yes # 设置为 yes 表示开启 AOF 持久化功能（默认 no，关闭）
查看 AOF 文件
被写入 AOF 文件的所有命令都是以 Redis 的命令请求协议格式（纯文本）保存，可以直接打开一个 AOF 文件，观察里面的内容。
[root@node-01 redis-5.0.9]# ll | grep *.aof
-rw-r--r--. 1 root root 60 3月 9 13:10 appendonly.aof
[root@node-01 redis-5.0.9]# cat appendonly.aof
AOF 持久化的实现
AOF 持久化功能的实现可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤
命令追加
当 AOF 持久化功能开启后，Redis 服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓存区的末尾
文件写入和同步
redis.conf 配置中的 appendfsync 选项决定不同 AOF 持久化方式
| appendfsync 选项值 | 效率 | 安全性 | 含义 |
|---|---|---|---|
| always | 最慢 | 最安全 | 将 aof_buf 缓存区中的所有内容写入并同步到 AOF 文件 |
| everysec（默认） | 快 | 安全 | 将 aof_buf 缓存区中的所有内容写入到 AOF 文件，如果上次同步 AOF 文件的时间超过 1 秒钟，才对 AOF 文件进行同步 |
| no | 最快 | 最不安全 | 将 aof_buf 缓存区中的所有文件写入到 AOF 文件，但并不对 AOF 文件进行同步，何时同步由操作系统来决定 |
注：appendfsync 选项的值直接决定 AOF 持久化功能的效率和安全性
AOF 文件的加载与数据还原
因为 AOF 文件记录了 Redis 服务器处理的所有写命令，所以服务器只要读入并重新执行一遍 AOF 文件，就可以还原服务器关闭之前的数据库状态。
Redis 服务器在启动时，会自动载入和执行 AOF 文件中保存的命令来还原 Redis 服务器状态，如下：
1602:M 09 Mar 2021 13:18:17.718 * DB loaded from append only file: 0.000 seconds # 加载 AOF 文件
1602:M 09 Mar 2021 13:18:17.718 * Ready to accept connections
AOF 文件重写
为何要 AOF 文件重写
因为 AOF 持久化是通过保存被执行的写命令来记录数据库状态，所以随着 Redis 服务器处理写命令增多，AOF 文件内容会越来越多，文件也会越来越大，如果不加以控制，文件太大会对 Redis 服务器造成影响，并且还原 AOF 文件所需的时间也会越长。
为了解决 AOF 体积膨胀的问题，Redis 提供 AOF 文件重写（rewrite）功能
通过 AOF 文件重写功能，Redis 服务器可以创建一个新的 AOF 文件来替代现有的 AOF 文件，新旧文件保存数据库状态相同，但新 AOF 文件不会包含冗余命令（优化），所以新 AOF 文件体积更小。
AOF 文件重写原理
-
在重写即将开始之际，redis 会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的 AOF 文件，并将其包含的指令进行分析压缩并写入到一个临时文件中
-
与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外
-
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新 AOF 文件中
-
当追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都会追加到新的 AOF 文件中了
AOF 持久化优缺点
AOF 持久化优点
-
故障数据不丢失：可以设置 appendfsync 策略，一般默认是 everysec，也可以设置每次写入追加，所以即使服务器故障宕机，也最多丢失一秒数据
-
AOF 文件重写：当 AOF 文件大小到达一定程度的时候，后台会自动的去执行 AOF 文件重写，此过程不会影响主进程，重写完成后，新的写入将会写到新的 AOF 中，旧的就会被删除掉。
AOF 持久化缺点
-
性能相对较差：AOF 持久化操作模式决定会对 Redis 的性能有所损耗
-
AOF 文件更大：尽管有 AOF 文件重写，但是随着 Redis 服务器写操作增多，AOF 文件依然会增大
-
恢复速度更慢：还原数据库状态是通过加载 AOF 文件内容，逐条执行记录的写操作，显然速度比 RDB 更慢
如何选择 Redis 持久化策略
对于应该选择 RDB 还是 AOF，官方的建议是两个同时使用，这样可以提供更可靠的持久化方案。
总结
-
AOF 文件通过保存所有修改数据库的写命令来记录服务器的数据库状态
-
AOF 文件中的所有命令都以 Redis 命令请求协议的格式保存
-
写命令会先保存 AOF 缓冲区里面，之后再定期写入并同步到 AOF 文件
-
appendfsync 选项的不同值对 AOF 持久化功能的安全性以及 Redis 服务器的性能有很大影响
-
服务器启动会自动加载 AOF 文件并执行里面的命令，这样就可以还原 Redis 服务器关闭前的数据库状态
-
AOF 重写可以产生一个新的 AOF 文件，这个文件比原有的 AOF 文件保存的内容相同，但经过去冗余等优化后，体积更小
-
AOF 重写原理（确保 AOF 重写时尽量不阻塞 Redis 服务器正常工作）
-
