RDB 持久化
描述
会在指定的时间间隔内将内存中的数据集快照写入磁盘。
工作机制
Redis 调用 fork()。于是我们有了父子两个进程。
子进程开始将数据集写入一个临时 RDB 文件。
当子进程完成了新 RDB 文件，替换掉旧文件。
优点
(1). RDB 文件适合用于备份，是一种表示某个即时点数据集的紧凑文件。例如，你可能想要每小时归档最近 24 小时的 RDB 文件，每天保存近 30 天的 RDB 快照。这允许你很容易的恢复不同版本的数据集以容灾。
(2). RDB 非常适合于灾难恢复。作为一个紧凑的单一文件，可以被传输到其他设备上。
(3). 性能最大化。因为 Redis 父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘 IO 这样的操作。
(4). RDB 在重启保存了大数据集的实例时比 AOF 要快。
缺点
(1). 若想保证数据的高可用性能，即最大限度地避免数据丢失，RDB 将不是一个很好的选择。因为每隔一段时间会进行一次备份，若中途出现宕机，那最近的修改就会丢失。
(2). RDB 经常调用 fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且 CPU 性能不够强大的话，Redis 会停止服务客户端几毫秒甚至一秒。AOF 也需要 fork()，但是你可以调整多久频率重写日志而不会有损持久性。
AOF 持久化（append-on file）
描述
快照并不是非常具有可持久性。如果电脑停机了，电源线断了，最近写入 Redis 的数据将会丢失。所以 AOF 是一个替代方案，是 Redis 的完全可持久性策略。
工作机制
在服务端记录每次收到的写操作，将会被追加到 AOF 中。在服务器启动时会根据这些操作重建原始数据集。
如何开启
appendonly yes
三种同步方式的配置
// 每次有数据修改发生时都会写入AOF文件 appendfsync always // 每秒钟同步一次，该策略为AOF的缺省策略 appendfsync everysec // 从不同步。高效但是数据不会被持久化 appendfsync no
优点
(1). 更高的数据安全性，即数据持久性。有三种同步策略：每秒同步，每修改同步，不同步。默认为每秒同步策略，写性能也仍然很不错（同步是由后台线程完成的，主线程继续努力地执行写请求）。
(2). AOF 日志是一个追加文件，即使出现宕机现象，也不会破坏文件的已有内容。即使由于某种原因文件末尾是一个写到一半的命令（磁盘满或者其他原因），redis-check-aof 工具也可以很轻易的修复。
(3). AOF 文件变得很大时，Redis 会自动在后台进行重写。重写是绝对安全的，因为 Redis 继续往旧的文件中追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦第二个文件创建完毕，Redis 就会切换这两个文件，并开始往新文件追加
(4). AOF 文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易的导出一个 AOF 文件。例如，即使你不小心错误地使用 FLUSHALL 命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启 Redis 就可以。
缺点
(1). 对同样的数据集，AOF 文件通常要大于等价的 RDB 文件。
(2). AOF 可能比 RDB 慢，这取决于准确的 fsync 策略。通常 fsync 设置为每秒一次的话性能仍然很高，如果关闭 fsync，即使在很高的负载下也和 RDB 一样的快。不过，即使在很大的写负载情况下，RDB 还是能提供能好的最大延迟保证。
(3). 在过去，我们经历了一些针对特殊命令(例如，像 BRPOPLPUSH 这样的阻塞命令)的罕见 bug，导致在数据加载时无法恢复到保存时的样子。这些 bug 很罕见，我们也在测试套件中进行了测试，自动随机创造复杂的数据集，然后加载它们以检查一切是否正常，但是，这类 bug 几乎不可能出现在 RDB 持久化中。为了说得更清楚一点：Redis AOF 是通过递增地更新一个已经存在的状态，像 MySQL 或者 MongoDB 一样，而 RDB 快照是一次又一次地从头开始创造一切，概念上更健壮。但是，1)要注意 Redis 每次重写 AOF 时都是以当前数据集中的真实数据从头开始，相对于一直追加的 AOF 文件(或者一次重写读取老的 AOF 文件而不是读内存中的数据)对 bug 的免疫力更强。2)我们还没有收到一份用户在真实世界中检测到崩溃的报告。
如何修复损坏的 AOF 文件
文件损坏后 Redis 就无法装载了，可以使用下面步骤解决这个问题
(1). 创建 AOF 的一个拷贝用于备份。
(2). 使用 Redis 自带的 redis-check-aof 工具来修复原文件：$ redis-check-aof --fix <filename>
(3). 使用 diff -u 来检查两个文件有什么不同。用修复好的文件来重启服务器。
如何选择持久化机制
(1). RDB
(2). AOF
(3). 可以完全禁止持久化。
(4). RDB + AOF
我们该选谁：
通常来说，应该同时使用这两种持久化方法。
如果你很关注你的数据，但是仍然可以接受灾难时有几分钟的数据丢失，你可以只单独使用 RDB。
有很多用户单独使用 AOF，但是我们并不鼓励这样，因为时常进行 RDB 快照非常方便于数据库备份，启动速度也较之快，还避免了 AOF 引擎的 bug。
如何从 RDB 切换到 AOF
(1). 备份你最新的 dump.rdb 文件。
(2). 把备份文件放到一个安全的地方。
(3). 发送以下两个命令。
(4). redis-cli config set appendonly yes（开启 AOF。Redis 会阻塞以生成初始转储文件，然后打开文件准备写，开始追加写操作。）
(5). redis-cli config set save ""（关闭快照持久化。这一步是可选的，如果你想同时开启这两种持久化方法。）
(6). 确保你的数据库含有其包含的相同的键的数量。
(7). 确保写被正确的追加到 AOF 文件。
注：记得编辑你的 redis.conf 文件来开启 AOF，否则当你重启服务器时，你的配置修改将会丢失，服务器又会使用旧的配置。