Redis的持久化

Redis是一个键值对数据库，是内存数据库，

Redis 提供了不同级别的持久化方式:

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.

RDB

RDB所产生的是一个经过压缩的二进制文件

RDB文件的创建与载入

SAVE和BGSAVE命令可以产生RDB文件

• SAVE命令会阻塞进程，直到RDB文件创建完成。在阻塞期间不能处理任何请求
• BGSAVE命令会派生一个子进程，子进程创建，父进程处理请求

RDB文件载入是在服务器启动时自动执行的，故没有专门的命令，只要启动时检测到RDB的存在就会自动载入（在载入RDB文件期间，服务器会一直阻塞，直到载入完成）

由于AOF更新频率比RDB更新频率高，故如图

自动间隔性保存

用户通过SAVE选项设置多个保存条件，但以下任意一个条件满足，就会执行BGSAVE

• 服务器在900s内，对数据库至少一次修改
• 服务器在300s内，对数据库至少十次修改
• 服务器在60s内，对数据库至少10000次修改

通过一下设计实现了改功能

• saveparams一个数组，保存了一个save选项的设置保存条件
• dirty计数器记录距离上一次成功执行SAVE或BGSAVE后，对数据库进行了多少次修改
• lastsave是时间戳，记录上一次成功的时间

RDB文件结构

• 五个字节的REDIS字符串（载入文件时，快速检查所载入的文件时候包含RDB文件）
• 四个字节的版本号（记录了RDB文件的版本号）
• databases部分包含零或任意多个数据库，以及其中的数据
• 一个字节的EOF常量（标志RDB文件正文内容结束，读到此值时，所有键值对皆已载入完毕）
• 八个自己的校验和（保存由REDIS,db_version,databases,EOF四个部分计算得出的校验和，以此来检查RDB文件是否出现出错或损坏）

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

被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的，Redis的命令请求协议是纯文本格式
AOF持久化得实现可分为命令追加，文件写入，文件同步
命令追加

服务器在执行完一个命令后，以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾

文件的写入与同步

AOF文件的载入过程如下

AOF的重写

AOF持久化通过保存被执行的写命令来记录数据库状态，随着运行时间的流逝，AOF文件内容会越来越多，体积也会越来越大，故而提供了重写的功能

从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录的多条命令，这就是原理
AOF重写程序aof_rewrite可以很好的完成创建一个新的AOF文件，但是，Redis服务器是使用单线程来处理命令请求的，调用这个函数会被长时间阻塞
故而，把AOF重写放入子进程成了更好的选择
一方面，子进程重写，父进程可以处理请求，另一方面，子进程带有数据副本，不是线程，避免了使用锁

但是在重写期间，还在处理请求，新的请求可能会对数据库进行修改，使得前后状态不一致，故而采用了下图的方法

• AOF缓冲区中内容会定期写入和同步到AOF文件
• 所有写命令也会被记录到AOF重写缓冲区中
• 当完成重写后，子进程会向父进程发一个信号，父进程接到后，调用信号处理，并且，将A0F重写缓冲区中的所用内容写到新的AOF文件中，对新的AOF文件改名，原子的覆盖现有的文件
• 只有信号处理函数执行会造成阻塞，对性能造成影响最低

AOF 优点

• 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
• 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）。