redis 是一种key-value 数据库，所有的数据存储都在内存，相较于其他内存数据库，redis 会将数据不定期的同步到磁盘中，redis 在数据持久化方面提供了两种方式，一种是 RDB 持久化方式，另一种是 AOF 持久化方式。
RDB 持久化
RDB 持久化是指在指定的时间间隔将内存中的数据集快照写入磁盘的方式，实际过程是fork 一个子进程（这个子进程会占用和redis-server相同大小的内存，也经常导致redis 服务器内存撑爆的原因）将数据集写入临时文件，写入成功后再替换之前的文件，用二进制压缩存储。
- 常用配置
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
- 优点
- RDB是redis 提供的时间非常紧凑的数据持久化方式。RDB文件非常适合备份。例如，您可能希望在最近的24小时内每小时存档一次RDB文件，并在30天之内每天保存一次RDB快照。这使您可以在发生灾难时轻松还原数据集的不同版本。
- RDB对于灾难恢复非常有用，它是一个紧凑的文件，可以传输到远程数据中心或Amazon S3（可能已加密）上。
- RDB最大限度地提高了Redis的性能，因为Redis父进程为了持久化所需要做的唯一工作就是分派一个孩子，其余的都将做。父实例将永远不会执行磁盘I / O等操作。
- 与AOF相比，RDB允许大型数据集更快地重启。
- 缺点
- 如果您需要最大程度地减少数据丢失的可能性（如果Redis停止工作，例如在断电之后），则RDB不好。您可以配置生成RDB的不同保存点（例如，在至少五分钟后，对数据集进行100次写入，但是您可以有多个保存点）。但是，通常会每隔五分钟或更长时间创建一次RDB快照，因此，如果Redis出于任何原因在没有正确关闭的情况下停止工作，则应该准备丢失最新的数据分钟。
- RDB需要经常使用fork（）才能使用子进程将其持久化在磁盘上。如果数据集很大，Fork（）可能很耗时，并且如果数据集很大且CPU性能不佳，则可能导致Redis停止为客户端服务几毫秒甚至一秒钟。AOF还需要fork（），但您可以调整要重写日志的频率，而无需在持久性上进行权衡。
AOF 持久化
AOF 持久化是一种以日志记录redis server 所处理的每一个写、删除操作（查询操作不会记录），以文本的方式记录，可以通过打开文本的方式查看详细的操作记录。
- 配置项
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。
- 优点
- 使用AOF Redis更加持久：您可以使用不同的fsync策略：完全没有fsync，每秒fsync，每个查询fsync。使用默认策略fsync时，每秒的写入性能仍然很好（fsync是使用后台线程执行的，并且在没有进行fsync的情况下，主线程将尽力执行写入操作。）但是您只能损失一秒钟的写入时间。
- AOF日志是仅追加的日志，因此，如果断电，则不会出现寻道或损坏问题。即使由于某种原因（磁盘已满或其他原因）以半写命令结束日志，redis-check-aof工具也可以轻松修复它。
- Redis太大时，Redis能够在后台自动重写AOF。重写是完全安全的，因为Redis继续追加到旧文件时，会生成一个全新的文件，其中包含创建当前数据集所需的最少操作集，一旦准备好第二个文件，Redis会切换这两个文件并开始追加到新的那一个。
- AOF以易于理解和解析的格式包含所有操作的日志。您甚至可以轻松导出AOF文件。例如，即使您使用FLUSHALL命令刷新了所有错误文件，如果在此期间未执行任何日志重写操作，您仍然可以保存数据集，只是停止服务器，删除最新命令，然后重新启动Redis。
- 缺点
- 对于相同的数据集，AOF文件通常大于等效的RDB文件。
- 根据确切的fsync策略，AOF可能比RDB慢。通常，在将fsync设置为每秒的情况下，性能仍然很高，并且在禁用fsync的情况下，即使在高负载下，它也应与RDB一样快。即使在巨大的写负载情况下，RDB仍然能够提供有关最大延迟的更多保证。
- 过去，我们在特定命令中遇到过罕见的错误（例如，其中一个涉及阻止命令，例如BRPOPLPUSH），导致生成的AOF在重载时无法重现完全相同的数据集。这些错误很少见，我们在测试套件中进行了测试，自动创建了随机的复杂数据集，然后重新加载它们以检查一切是否正常。但是，RDB持久性几乎是不可能的。更明确地说：Redis AOF通过增量更新现有状态来工作，就像MySQL或MongoDB一样，而RDB快照一次又一次地创建所有内容，从概念上讲更健壮。但是-1）应当注意，每次Redis重写AOF时，都会从数据集中包含的实际数据开始从头开始重新创建AOF，与始终附加AOF文件（或重写为读取旧AOF而不是读取内存中的数据）相比，提高了对错误的抵抗力。2）我们从未收到过有关真实环境中检测到的AOF损坏的用户报告。
