1、还是先看看官方文档:
注: AOF 持久化日志向服务器获取每次发生的写操作，这日志在服务器启动的时候执行，以恢复原来的数据集。这些写命令会以redis自身协议的相同格式被日志化。当这个日志文件太大时，redis能够在后台重写这日志。（读操作不记录，操作只需追加文件内容，不允许改写文件。）
如果你愿意，你可以完全不持久化，这种情况通常发生在服务器运行时数据存在就行。
在同一个实例中可以结合使用 AOF 和 RDB。在这种情况下，Redi开启时会重新执行 AOF 文件，以使得恢复原来的数据集（因为这种恢复最完整）。
2、具体看看如何操作:
a、设置 redis.conf文件，为了让配置文件不太复杂，使用 cp 命令 备份一个 redis_aof.conf文件。
注: 默认为 appendonly no，在之前的配置文件的相关信息中介绍过，修改appendonly yes 表示开启 AOF。
b、 在写入操作时，redis会在工作目录中创建出一个appendonly.aof（即redis持久化日志文件）。
c、执行flushall命令后，后关闭服务器，使用ls -l 命令查看文件，再使用cat 命令查看appendonly.aof文件。（可以看到在同一个实例中可以结合使用 AOF 和 RDB。）
注: 如图示，可以看到appendonly.aof记录了所有写操作命令，包括 select 0，flushall等，如果重启服务器，使用 keys 进行查询，还是会显示空结果。
d、把 appendonly.aof 文件中最后的 flushall 删除后，在启动服务器。
注: 可以看到数据已经被恢复
e、关闭服务器后，破坏appendonly.aof文件，再启动服务器。
发现破坏文件后，服务器已无法启动。由此可知， 在同一个实例中可以结合使用 AOF 和 RDB，服务器开启时redis优先从appendonly.aof文件中读取到内存，后执行命令。
f、键入 /usr/local/bin/redis-check-aof --fix appendonly.aof 指令后，可以重新启动redis服务器。
3、redis.conf 下关于 AOF 的其他相关配置:
a、appendfsync 配置操作:
如图示，可以看到:
always: 同步持久化，每次发生数据变更时立即把操作记录到磁盘中，这中模式安全，但是性能差。
everysec: 出厂默认设置，异步操作，每秒记录。如果在一秒内荡机，这一秒内的数据将会丢失。
no: 即不把数据变更操作记录在磁盘中。
b、no-appendfsync-on-rewrite: 如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes，这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区
5、AOF 的 rewrite:
a、AOF 采用文件追加方式，这意味这文件将会越来越大。针对这一问题，新增了重写机制，当AOF 文件的大小超过了所设定的阙值（临界值）时， Redis 会启动 AOF 文件的内容压缩，只保存数据的最小指令集。
b、重写原理:
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename）。遍历新进程的内存中数据，每条记录有一条Set语句。
重写aof文件操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这一点和快照类似。
c、Redis会记录上次重写时的 AOF 大小时，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于64M时触发。
6、AOF 相对于 RDB 的劣势:
a、相同数据集的数据而言，aof 文件 要远大于rdb 文件，恢复速度慢于rdb。
b、aof 运行效率要慢于rdb,每秒同步的策略效率较好，不同步效率和rdb相同。