Redis的AOF持久化策略是将发送到redis服务端的每一条命令都记录下来，并且保存到硬盘中的AOF文件中，类似打日志文件，来一条命令就记录一条。
AOF设置
AOF文件的位置和RDB文件的位置相同，都是通过dir参数设置，默认的文件名是appendonly.aof，可以通过appendfilename参数来修改。
AOF测试
当客户端向服务器发送一些redis命令时，Redis会将所执行的命令记录到aof文件中，如下所示：
当redis服务器重启后，会将执行该aof文件，达到数据恢复的目的。
AOF文件重写
为什么要重写？重写可以去除数据的中间执行过程，直接保留最终数据命令。
举个栗子：比如在redis客户端对key执行了一系列命令
set count 1 //初始值为1
incr count // 加1
incr count //加1
decr count //减1
这个时候结果为
get count
“2”
如果不进行AOF重写的话，进行AOF文件恢复的时候，Redis会执行AOF文件中的每一条命令,并最终得到 count 为2 。
进行AOF重写后，相当于把中间的计算过程略去。直接把计算得到的结果设置进redis，相当于仅执行了一条命令 set count 2。
可以使用BGREWRITEAOF命令来重写AOF文件。
重写策略
重写策略的参数设置：
auto-aof-rewrite-percentage 100
当前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时，会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据。
auto-aof-rewrite-min-size 64mb
限制了允许重写的最小AOF文件大小，通常在AOF文件很小的时候，即使其中有些冗余的命令也是可以忽略的。
Redis优秀的性能是由于其将所有的数据都存储在内存中，同样memcached也是这样做的，但是为什么redis能够脱颖而出呢，很大程度上是因为Redis有出色的持久化机制，能够保证服务器重启后，数据不会丢失。下面来看看Redis是如何持久化的。
Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。这两种方式可以单独使用其中一种，或者混合使用。
RDB方式介绍
RDB方式是通过快照完成的，当符合一定条件时Redis会自动将内存中的所有数据进行快照，并且存储到硬盘上。就像拍照一样，将这一瞬间的所有东西都保存下来。进行快照的条件在配置文件中指定。主要有两个参数构成：时间和改动的键值的个数，即当在指定时间内被更改的键的个数大于执行数值时，就会进行快照。RDB是Redis的默认持久化方式。
RDB方式配置
找到Redis的配置文件：redis.conf
1） 设置触发条件：
2) 设置rdb文件路径
默认rdb文件存放路径是当前目录，文件名是：dump.rdb。可以在配置文件中修改路径和文件名，分别是dir和dbfilename
Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存，一般情况下1GB的快照文件载入到内存的时间大约20-30分钟。
RDB如何进行快照
RDB的快照过程：
1） Redis使用fork函数复制一份当前进程（父进程）的副本；
2） 父进程继续接受并处理客户端发来的命令，而子进程开始将内存中的数据写入到硬盘中的临时文件；
3） 当子进程写入完成所有数据后会用该临时文件替换旧的RDB文件。
手动快照：
如果没有触发自动快照，可以对redis进行手动快照操作，SAVE和BGSAVE都可以执行手动快照，两个命令的区别是前者是由主进程进行快照操作，会阻塞其他请求；而后者是通过fork子进程进行快照操作。
注意：
由于redis使用fork来复制一份当前进程，那么子进程就会占有和主进程一样的内存资源，比如说主进程8G内存，那么在备份的时候必须保证有16G内存，要不然会启用虚拟内存，性能非常差。
RDB文件的压缩
RDB文件过大时，是可以压缩的，Redis默认开启压缩，当然也可以通过配置rdbcompression参数来禁用压缩。
压缩和不压缩的优缺点：
压缩：
优点：减少磁盘存储空间缺点：消耗CPU资源
不压缩：
优点：不消耗CPU资源缺点：占用磁盘空间多 RDB 优点RDB 是一种表示某个即时点的 Redis 数据的紧凑文件。RDB 文件适合用于备份。例如，你可能想要每小时归档最近 24 小时的 RDB 文件，每天保存近 30 天的 RDB 快照。这允许你很容易的恢复不同版本的数据集以容灾。RDB 非常适合于灾难恢复，作为一个紧凑的单一文件，可以被传输到远程的数据中心，或者是 Amazon S3(可能得加密)。RDB 最大化了 Redis 的性能，因为 Redis 父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘 IO 这样的操作。RDB 在重启保存了大数据集的实例时比 AOF 要快。RDB 缺点当你需要在 Redis 停止工作(例如停电)时最小化数据丢失，RDB 可能不太好。你可以配置不同的保存点。然而，你通常每隔 5 分钟或更久创建一个 RDB 快照，所以一旦 Redis 因为任何原因没有正确关闭而停止工作，你就得做好最近几分钟数据丢失的准备了。RDB 需要经常调用 fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且 CPU 性能不够强大的话，Redis 会停止服务客户端几毫秒甚至一秒。AOF 也需要 fork()，但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。AOF 优点使用 AOF Redis 会更具有可持久性(durable)：你可以有很多不同的 fsync 策略：没有 fsync，每秒 fsync，每次请求时 fsync。使用默认的每秒 fsync 策略，写性能也仍然很不错(fsync 是由后台线程完成的，主线程继续努力地执行写请求)，即便你也就仅仅只损失一秒钟的写数据。AOF 日志是一个追加文件，所以不需要定位，在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof 工具也可以很轻易的修复。AOF 文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易的导出一个 AOF 文件。例如，即使你不小心错误地使用 FLUSHALL 命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启 Redis 就可以。AOF 缺点对同样的数据集，AOF 文件通常要大于等价的 RDB 文件。AOF 可能比 RDB 慢，这取决于准确的 fsync 策略。通常 fsync 设置为每秒一次的话性能仍然很高，如果关闭 fsync，即使在很高的负载下也和 RDB 一样的快。不过，即使在很大的写负载情况下，RDB 还是能提供能好的最大延迟保证。 RDB和AOF如何取舍通常来说，你应该同时使用这两种持久化方法，以达到和 PostgreSQL 提供的一样的数据安全程度。如果你很关注你的数据，但是仍然可以接受灾难时有几分钟的数据丢失，你可以只单独使用 RDB。有很多用户单独使用 AOF，但是我们并不鼓励这样，因为时常进行 RDB 快照非常方便于数据库备份，启动速度也较之快，还避免了 AOF 引擎的 bug。
如何选择？ 那就需要看需求、看服务器资源情况了。