Redis持久化

持久化

为什么要持久化？为了重启计算机时恢复数据。

RDB

在指定时间间隔内将内存中的数据写入RDB文件（dump.rdb），保存的是全量数据。可以在redis启动时恢复到内存中。

两种回写方式（回写时Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的。
当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件。这样在任何时候出现故障，Redis的RDB文件都总是可用的。）

save(同步回写)：由redis的主进程直接向磁盘回写数据。由于redis是单线程工作的，会阻塞其他操作，在数据大的情况下会导致系统假死很长时间，一般不推荐。
bgSave(异步回写)：主进程fork出一个子进程，由子进程将数据写入RDB文件，同时主进程还可以处理来自客户端的请求。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法。在小内存的进程上做一个fork（相当于复制了一份父进程）,不需要太多资源，但当这个进程的内存空间以Ｇ为单位时，fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端。例如在16G内存的主机上fork 14G内存的进程呢，肯定会报内存无法分配的。并且越是改动频繁的主机上fork也越频繁，fork操作本身的代价恐怕也不会比假死好多少。

配置：

save 900 1    #当有一条Keys数据被改变时，900秒刷新到Disk一次
save 300 10   #当有10条Keys数据被改变时，300秒刷新到Disk一次
save 60 10000 #当有10000条Keys数据被改变时，60秒刷新到Disk一次

优势：

1、RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

2、RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。

3、RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

4、RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

劣势：

1、数据丢失风险大。例如每5分钟进行一次RDB持久化，在这5分钟期间，出现断电或宕机情况，这5分钟的数据就会丢失。（你可能会说我每秒持久化一次，但是RDB持久化需要保存整个数据集的状态，很耗时，每秒持久化是不现实的） 。

2、每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。？？没懂

AOF：以操作日志的形式，将对数据的修改操作追加到AOF的磁盘文件，在redis重启时，通过执行这些命令来还原数据。

配置：

appendonly yes       #启用AOF持久化方式
# appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
# appendfsync no     #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。

优点
1、数据丢失率较低，就算发生故障停机，也最多只会丢失一秒钟的数据。

2、AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。

3、Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

4、AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

缺点
1、对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

2、根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB（在RDB未回写期间） 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

3、AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的

AOF文件变大问题

主进程fork出一个新进程来遍历进程内存中的数据，重新生成一个用于构建当前数据集的临时文件（里面记录的是构建当前数据要做的操作），在然后再替换到旧的日志文件（类似rdb的操作方式）。重写AOF文件时并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。默认触发是当aof文件大小是上次重写后大小的一倍且文件大于64M时触发。

注意：

当两种方式同时开启时，数据恢复redis会优先选择AOF恢复。一般情况下，只要使用默认开启的RDB即可，因为相对于AOF，RDB便于进行数据库备份，并且恢复数据集的速度也要快很多。
开启持久化缓存机制，对性能会有一定的影响，特别是当设置的内存满了的时候，更是下降到几百reqs/s。所以如果只是用来做缓存的话，可以关掉持久化。

如何选择

通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。
如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。
很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB。
因此，我们希望可以在未来（长远计划）统一AOF和RDB成一种持久化模式。

在数据恢复方面：
RDB的启动时间会更短，原因有两个：
一是RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。
另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。

参考：

redis两种持久化方式的优缺点

redis——持久化篇

Redis持久化-数据丢失及解决