1. 简介
以日志的形式来记录每个写操作，将redis执行的每个写操作记录下来（读操作不记录），只需追加文件但不可以改写文件，redis启动之初会重新构建数据，即redis重启后会将日志中的所有写指令重新执行一遍以达到数据重构的效果
2. 工作流程
| 1 | Client作为命令的来源，会有多个源头以及源源不断的请求命令。 |
| 2 | 在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。 |
| 3 | AOF缓冲会根据AOF缓冲区 同步文件的三种写回策略将命令写入磁盘上的AOF文件。 |
| 4 | 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称 AOF重写)，从而起到AOF文件压缩的目的。 |
| 5 | 当Redis Server 服务器重启的时候会从AOF文件载入数据。 |
3. 三种回写策略
- Always
同步回写，每个写命令执行完立刻同步的将日志写入磁盘中
- everysec
每秒回写，每个命令执行完，只是先把日志写到AOF文件内存缓冲区，每隔一秒将内存缓冲区的内容写入磁盘
- no
操作系统控制写回，每个命令执行完只是先把日志写到AOF内存缓冲区，再由操作系统决定何时将缓冲区内容写入磁盘
4. 优势和不足
5. 重写机制
5.1 简介
由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，
文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集
或者
可以手动使用命令 bgrewriteaof 来重新。
5.2 触发机制
- 自动触发
满足配置文件中的选项后，redis会记录上次重写时AOF的大小，默认配置是当AOF文件大小是rewire两倍且文件大小大于64M时触发
- 手动触发
客户端向服务器发送bgrewriteaof命令
5.3 重写原理
1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
