redis学习笔记四：redis的持久化

全量模式的持久化（RDB）

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照（snapshotting）存储，将内存中的数据不断写入二进制文件中，默认文件dump.rdb，可配置Redis在n秒内如果超过m个key被修改就自动保存快照。
例如：
save 900 1 #900秒内如果超过1个key被修改，则发起快照保存。
save 300 10 #300秒内如果超过10个key被修改，则快照保存。

Redis Server在多有db 中存储的key-value可以理解为Redis的一个状态。当发生写操作时，Redis就会从一个状态切换到另外一个状态。基于全量的持久化就是在某个时刻，将Redis的所有数据持久化到硬盘中，形成一个快照。当Redis 重启时，通过加载最近一个快照数据，可以将Redis 恢复至最近一次持久化状态上。

1、写入流程

Redis的全量写入包含2种方式：save 和 bgsave，两者的处理逻辑如下：

• save 可以由客户端显示触发的，也可以在redis shutdown 时触发。Save本身是单线程串行化的方式执行的，因此当数据量大时，有肯能会发生Redis Server的长时间卡顿。但是其备份期间不会有其他命令执行，因此备份在这一时刻是一致性的。
• bgsave 也可以由客户端显示触发、可以通过配置定时任务触发也可以在master-slave的分布式结构下由slave节点触发。bgsave命令在执行的时候，会fork一个子进程。子进程提交完成之后，会立即给客户端返回响应，备份操作在后台异步执行，在此期间不会影响Redis的正常响应。

对于bgsave来说，当父进程Fork完子进程之后，异步任务会将当前的内存状态作为一个版本进行复制。在复制过程中产生的变更，不会反映在这次备份当中。在Redis的默认配置当中，当满足下面任一条件时，会自动触发bgsave 的执行。

配置	seconds	changes
save	900	1
save	300	10
save	60	10000

bgsave相对于Save来说，其优势是异步执行，不影响后续的命令执行。但是Fork子进程时，涉及父进程的内存复制，此时会增加服务器的内存开销。当内存开销高到使用虚拟内存时，bgsave的Fork子进程会阻塞运行，可能会造成秒级的不可用。因此使用bgsave需要保证服务器空闲内存足够。

2、恢复流程

当Redis重新启动时，会从本地磁盘加载之前持久化的文件。当恢复完成之后，再受理后续的请求操作。

rdb文件

前面介绍了三种让服务器生成rdb文件的方式，无论是由主进程生成还是子进程来生成，其过程如下：

• 生成临时rdb文件，并写入数据。
• 完成数据写入，用临时文代替代正式rdb文件。
• 删除原来的db文件。

RDB优点

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
• RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB缺点

• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
• RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

增量模式的持久化（AOF）

RDB记录的是每个状态的全量数据，而AOF（append-only-file）记录的则是每条写命令的记录，通过所有写命令的执行，最后恢复出最终的数据状态。其文件的生成如下所示：

1、写入流程

Redis的AOF 包含3 种同步策略：

• always：每一次的刷新缓冲区，都会同步触发同步操作。因为每次的写操作都会触发同步，所以该策略会降低Redis的吞吐量，但是这种模式会拥有最高的容错能力。
• every second：每秒异步的触发同步操作，这种是Redis的默认配置。
• no：由操作系统决定何时同步，这种方式Redis无法决定何时落地，因此不可控。

命令	always	everysec	no
优点	不丢失数据	每秒1次fsync，丢1秒数据	无需设置
缺点	IO开销大，一般的STAT盘只有几百TPS	丢1秒数据	不可控

2、回放流程

AOF的回放时机也是在机器启动时，一旦存在AOF，Redis会选择增量回放。因为增量的持久化持续的写入磁盘，相比全量持久化，数据更加完整。回放的过程就是将AOF中存放的命令，重新执行一遍。完成之后再继续接受客户端的新命令。

AOF 优点

• 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.（由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上，这样aof方式的持久化也还是有可能会丢失一部分数据。可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机）
  AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

建议两种持久化方式同时使用

AOF模式的优化重写

随着Redis 持续的运行，会有大量的增量数据append 到AOF 文件中。为了减小硬盘存储和加快恢复速度，Redis 通过rewrite 机制合并历史AOF 记录。如下所示：

整个流程描述如下：

• 历史AOF：以快照的方式保存。
• 快照写入期间的增量：待快照写入完成之后append 到快照文件中。
• 后续的增量：写入新的AOF。

注：
1、如果希望数据在服务器运行的时候存在,可以不使用任何持久化方式.
2、可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.