开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 12 天，点击查看活动详情
AOF (Append Only File)
全量备份总是耗时的，Redis为我们提供了一种更加高效的持久化方式，即AOF（appendonlyfile）。此方式工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。默认情况下Redis没有开启AOF方式的持久化。
开启AOF持久化后，每执行一条更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。
Aof保存的是 appendonly.aof 文件
开启方式
appendonly no # 是否以append only模式作为持久化方式，默认使用的是rdb方式持久化，这种方式在许多应用中已经足够用了
appendfilename "appendonly.aof" # appendfilename AOF 文件名称
appendfsync everysec # appendfsync aof持久化策略的配置
# no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
# always表示每次写入都执行fsync，以保证数据同步到磁盘。
# everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
No-appendfsync-on-rewrite #重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性
Auto-aof-rewrite-min-size # 设置重写的基准值
Auto-aof-rewrite-percentage #设置重写的基准值
AOF 启动/修复/恢复
正常恢复：
- 启动：设置Yes，修改默认的
appendonly no，改为yes - 将有数据的aof文件复制一份保存到对应目录（config get dir）
- 恢复：重启redis然后重新加载
异常恢复：
- 启动：设置Yes
- 故意破坏
appendonly.aof文件！ - 修复：
redis-check-aof --fix appendonly.aof进行修复 - 恢复：重启 redis 然后重新加载
AOF 重写
AOF 采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件的大小 超过所设定的阈值时，Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。！
重写原理：
AOF 文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再 rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧 的aof文件，这点和快照有点类似！
触发机制：
- 手动触发
AOF重写可以由用户通过调用BGREWRITEAOF手动触发。
- 自动触发
服务器在AOF功能开启的情况下，会维持以下三个变量：
- aof_current_size（记录当前AOF文件大小的变量）
- aof_rewrite_base_size（记录最后一次AOF重写之后AOF文件大小的变量）
- aof_rewrite_perc（增长百分比变量）
每次当serverCron函数（服务器周期性操作函数）执行时，它会检查以下条件是否全部满足，如果全部满足的话，就触发自动的AOF重写操作：
-
没有BGSAVE命令（RDB持久化）/AOF持久化在执行。
-
没有BGREWRITEAOF在进行。
-
当前AOF文件大小要大于server.aof_rewrite_min_size（默认为1MB）或者在redis.conf配置的auto-aof-rewrite-min-size。
-
当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%）。
当前面三个条件已经满足，并且当前AOF文件大小比最后一次AOF重写的大小大一倍就会触发自动AOF重写。
4、总结
1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始 的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重 写，使得AOF文件的体积不至于过大。
3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
4、同时开启两种持久化方式
- 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF 文件保存的数据集要比RDB文件保存的数据集要完整。
- RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者 建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有 AOF可能潜在的Bug，留着作为一个万一的手段。
RDB 和 AOF ，我应该用哪一个？
一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。
