### **一、AOF持久化** AOF（append only file）持久化：以独立日志的方式记录每次写命令，删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用 是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。 **1、工作流程** 1、所有的写入命令追加到aof\_buf缓冲区中。 2、AOF会根据对应的策略向磁盘做同步操作。由appendfsync参数决定。 3、定期对AOF文件进行重写。重写策略由auto-aof-rewrite-percentage，auto-aof-rewrite-min-size两个参数决定。 ~~~ appendfsync参数有如下取值： no: don't fsync, just let the OS flush the data when it wants. Faster. 只调用系统write操作，不对AOF文件做fsync操作，同步硬盘操作由操作系统负责，通常同步周期最长为30s。 always: fsync after every write to the append only log. Slow, Safest. 命令写入到aof\_buf后，会调用系统fsync操作同步到文件中。 everysec: fsync only one time every second. Compromise. 只调用系统write操作，fsync同步文件操作由专门进程每秒调用一次。 默认值为everysec，也是建议值。 ~~~ **2、触发机制** 1）手动触发：直接调用bgrewriteaof命令 2）自动触发：与auto-aof-rewrite-percentage，auto-aof-rewrite-min-size两个参数有关。 触发条件：aof\_current\_size > auto-aof-rewrite-min-size 并且 (aof\_current\_size  - aof\_base\_size) / aof\_base\_size >= auto-aof-rewrite-percentage。其中，aof\_current\_size是当前AOF文件大小，aof\_base\_size 是上一次重写后AOF文件的大小，这两部分的信息可从info Persistence处获取。 **3、重写与还原** **重写流程：**       1）执行AOF重写请求。如果当前进程正在执行bgsave操作，重写命令会等待bgsave执行完后再执行。       2）父进程执行fork创建子进程。       3） fork操作完成后，主进程会继续响应其它命令。所有修改命令依然会写入到aof\_buf中，并根据appendfsync策略持久化到AOF文件中。       4）因fork操作运用的是写时复制技术，所以子进程只能共享fork操作时的内存数据，对于fork操作后，生成的数据，主进程会单独开辟一块aof\_rewrite\_buf保存。       5）子进程根据内存快照，按照命令合并规则写入到新的AOF文件中。每次批量写入磁盘的数据量由aof-rewrite-incremental-fsync参数控制，默认为32M，避免单次刷盘数据过多造成硬盘阻塞。       6） 新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。       7） 父进程将aof\_rewrite\_buf（AOF重写缓冲区）的数据写入到新的AOF文件中。       8） 使用新AOF文件替换老文件，完成AOF重写 **4、优缺点** 1）优点 * 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步 * 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容 * AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。 2）缺点 * 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快 * AOF常用的持久化策略是everysec，在这种策略下，fsync同步文件操作由专门线程每秒调用一次。当系统磁盘较忙时，会造成Redis主线程阻塞。 **5、配置** appendfsync always     #每次有数据修改发生时都会写入AOF文件。 appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。 appendfsync no          #从不同步。高效但是数据不会被持久化