Redis持久化 aof和rdb的原理配置（下）

三.AOF持久化（增量写入）

aof原理

以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

写入的数据具有可读性，同步时先写入缓冲区，再放入硬盘。如果直接写入硬盘，性能将取决于磁盘负载，并且放到缓冲区，可以提供各种同步策略。

过程：

• 1）所有的写入命令会追加到aof_buf（缓冲区）中。
• 2）AOF缓冲区根据对应的策略向硬盘做同步操作。
• 3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
• 4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。

aof触发情况

1.根据配置文件自动触发

aof优势和劣势

优势：

• 该机制可以带来更高的数据安全性，即数据持久性。根据策略不同，从而对数据安全性不同，可以在性能和安全区选择一个。
• 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。
• 如果日志过大，将自动启用rewrite机制。以append模式不断的将修改数据写入到老的磁盘文件中，同时还会创建一个新的文件用于记录此期间有哪些修改命令被执行，保证安全性。
• AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

劣势：

• 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
• 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

aof文件配置

在Redis的配置文件中存在三种同步方式，它们分别是：

1. #是否开启aof持久化。默认no，要打开
2. appendonly yes
3. #位置
4. appendfilename "appendonly.aof"
5. #每次有数据修改发生时都会写入AOF文件
6. #命令写入aof_buf后调用系统fsync操作同步AOF文件，fsync完成后线程返回
7. appendfsync always
8. #每秒钟同步一次，该策略为AOF的缺省策略
9. #命令写入aof_buf后调用系统write操作，write完成后线程返回。fsync同步文件操作由专门线程每秒调用一次
10. #这个模式兼顾了效率的同时也保证了数据的完整性，即使在服务器宕机也只会丢失一秒内对redis数据库做的修改
11. appendfsync everysec
12. #不加入缓冲区，直接写到硬盘，速度最快，不安全
13. #命令写入aof_buf后调用系统write操作，不对aof文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期最长30秒
14. #这种模式下效率是最快的，但对数据来说也是最不安全的，如果redis里的数据都是从后台数据库如mysql中取出来的，属于随时可以找回或者不重要的数据，那么可以考虑设置成这种模式。
15. appendfsync no

aof文件重写手动触发 bgrewriteaof

aof文件重写自动触发，配置文件

1. #新的aof文件大小是上次的aof文件的大小2倍（100）时，进行重写
2. auto-aof-rewrite-percentage 100
3. #表示运行AOF重写时文件最小体积， 默认为64MB
4. auto-aof-rewrite-min-size 64mb

aof数据恢复

• 将AOF备份放到配置文件指定的数据目录下，启动redis将会自动恢复。加载期间将会阻塞，无法进行其它操作。
• 上述方法不行，或者恢复的集群，可以使用redis-migrate-tool工具进行恢复。
• 可以使用pipline方式批量硬写入，但效率会低

四.总结

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。

启动加载流程：

• AOF持久化开启且存在AOF文件时， 优先加载AOF文件
• AOF关闭或者AOF文件不存在时， 加载RDB文件
• 加载AOF/RDB文件成功后， Redis启动成功
• AOF/RDB文件存在错误时， Redis启动失败并打印错误信息