Redis持久化原理(RDB)

在上一篇文章中，介绍了Redis的内存模型很重要，从这篇文章开始，将依次介绍Redis高可用相关的知识——持久化、复制(及读写分离)、哨兵、以及集群。
本文将先说明上述几种技术分别解决了Redis高可用的什么问题；而后详细介绍Redis的持久化技术，主要是RDB和AOF两种持久化方案；在介绍RDB和AOF方案时，不只介绍其做用及操做方法，同时介绍持久化实现的一些原理细节及须要注意的问题。最后，介绍在实际使用中，持久化方案的选择，以及常常遇到的问题等。

1、Redis高可用概述

咱们知道，在web服务器中，高可用是指服务器能够正常访问的时间，衡量的标准是在多长时间内能够提供正常服务（99.9%、99.99%、99.999% 等等）。可是在Redis语境中，高可用的含义彷佛要宽泛一些，除了保证提供正常服务(如主从分离、快速容灾技术)，还须要考虑数据容量的扩展、数据安全不会丢失等。
一、持久化：持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要做用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。

二、复制：复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操做的负载均衡和简单的故障恢复。缺陷：故障恢复没法自动化；写操做没法负载均衡；存储能力受到单机的限制。
三、哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操做没法负载均衡；存储能力受到单机的限制。
四、集群：经过集群，Redis解决了写操做没法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

2、Redis持久化概述

持久化的功能：Redis是内存数据库，数据都是存储在内存中，为了不进程退出致使数据的永久丢失，须要按期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘；当下次Redis重启时，利用持久化文件实现数据恢复。除此以外，为了进行灾难备份，能够将持久化文件拷贝到一个远程位置。

Redis持久化分为RDB持久化和AOF持久化：前者将当前数据保存到硬盘，后者则是将每次执行的写命令保存到硬盘（相似于MySQL的binlog）；因为AOF持久化的实时性更好，即当进程意外退出时丢失的数据更少，所以AOF是目前主流的持久化方式，不过RDB持久化仍然有其用武之地。

3、RDB持久化

RDB持久化是将当前进程中的数据生成快照保存到硬盘(所以也称做快照持久化)，保存的文件后缀是rdb；当Redis从新启动时，能够读取快照文件恢复数据。

1. 触发条件

RDB持久化的触发分为手动触发和自动触发两种。
1) 手动触发
save命令和bgsave命令均可以生成RDB文件。
save命令会阻塞Redis服务器进程，直到RDB文件建立完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。

save

而bgsave命令会建立一个子进程，由子进程来负责建立RDB文件，父进程(即Redis主进程)则继续处理请求。

bgsave

bgsave命令执行过程当中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，所以save已基本被废弃，线上环境要杜绝save的使用；后文中也将只介绍bgsave命令。此外，在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化；下面介绍自动触发RDB持久化的条件。

自动触发

save m n
自动触发最多见的状况是在配置文件中经过save m n，指定当m秒内发生n次变化时，会触发bgsave。
例如，查看redis的默认配置文件(Linux下为redis根目录下的redis.conf)，能够看到以下配置信息：

其中save 900 1的含义是：当时间到900秒时，若是redis数据发生了至少1次变化，则执行bgsave；save 300 10和save 60 10000同理。当三个save条件知足任意一个时，都会引发bgsave的调用。

save m n的实现原理

Redis的save m n，是经过serverCron函数、dirty计数器、和lastsave时间戳来实现的。
serverCron是Redis服务器的周期性操做函数，默认每隔100ms执行一次；该函数对服务器的状态进行维护，其中一项工做就是检查 save m n 配置的条件是否知足，若是知足就执行bgsave。

dirty计数器是Redis服务器维持的一个状态，记录了上一次执行bgsave/save命令后，服务器状态进行了多少次修改(包括增删改)；而当save/bgsave执行完成后，会将dirty从新置为0。

例如，若是Redis执行了set mykey helloworld，则dirty值会+1；若是执行了sadd myset v1 v2 v3，则dirty值会+3；注意dirty记录的是服务器进行了多少次修改，而不是客户端执行了多少修改数据的命令。

astsave时间戳也是Redis服务器维持的一个状态，记录的是上一次成功执行save/bgsave的时间。
save m n的原理以下：每隔100ms，执行serverCron函数；在serverCron函数中，遍历save m n配置的保存条件，只要有一个条件知足，就进行bgsave。对于每个save m n条件，只有下面两条同时知足时才算知足：
（1）当前时间-lastsave > m
（2）dirty >= n
save m n 执行日志
下图是save m n触发bgsave执行时，服务器打印日志的状况：

其余自动触发机制
除了save m n 之外，还有一些其余状况会触发bgsave：
在主从复制场景下，若是从节点执行全量复制操做，则主节点会执行bgsave命令，并将rdb文件发送给从节点
执行shutdown命令时，自动执行rdb持久化，以下图所示：

2. 执行流程

前面介绍了触发bgsave的条件，下面将说明bgsave命令的执行流程

图片中的5个步骤所进行的操做以下：
1) Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof（后面会详细介绍该命令）的子进程，若是在执行则bgsave命令直接返回。bgsave/bgrewriteaof 的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操做，可能引发严重的性能问题。
2) 父进程执行fork操做建立子进程，这个过程当中父进程是阻塞的，Redis不能执行来自客户端的任何命令
3) 父进程fork后，bgsave命令返回”Background saving started”信息并再也不阻塞父进程，并能够响应其余命令
4) 子进程建立RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
5) 子进程发送信号给父进程表示完成，父进程更新统计信息

3. RDB文件

RDB文件是通过压缩的二进制文件，下面介绍关于RDB文件的一些细节。
存储路径
RDB文件的存储路径既能够在启动前配置，也能够经过命令动态设定。
配置：dir配置指定目录，dbfilename指定文件名。默认是Redis根目录下的dump.rdb文件。
动态设定：Redis启动后也能够动态修改RDB存储路径，在磁盘损害或空间不足时很是有用；执行命令为config set dir {newdir}和config set dbfilename {newFileName}

1) REDIS：常量，保存着”REDIS”5个字符。
2) db_version：RDB文件的版本号，注意不是Redis的版本号。
3) SELECTDB 0 pairs：表示一个完整的数据库(0号数据库)，同理SELECTDB 3 pairs表示完整的3号数据库；只有当数据库中有键值对时，RDB文件中才会有该数据库的信息(上图所示的Redis中只有0号和3号数据库有键值对)；若是Redis中全部的数据库都没有键值对，则这一部分直接省略。其中：SELECTDB是一个常量，表明后面跟着的是数据库号码；0和3是数据库号码；pairs则存储了具体的键值对信息，包括key、value值，及其数据类型、内部编码、过时时间、压缩信息等等。
4) EOF：常量，标志RDB文件正文内容结束。
5) check_sum：前面全部内容的校验和；Redis在载入RBD文件时，会计算前面的校验和并与check_sum值比较，判断文件是否损坏。
Redis默认采用LZF算法对RDB文件进行压缩。虽然压缩耗时，可是能够大大减少RDB文件的体积，所以压缩默认开启；能够经过命令关闭：

config set rdbcompression no

须要注意的是，RDB文件的压缩并非针对整个文件进行的，而是对数据库中的字符串进行的，且只有在字符串达到必定长度(20字节)时才会进行。

4. 启动时加载

RDB文件的载入工做是在服务器启动时自动执行的，并无专门的命令。可是因为AOF的优先级更高，所以当AOF开启时，Redis会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。
Redis载入RDB文件时，会对RDB文件进行校验，若是文件损坏，则日志中会打印错误，Redis启动失败。

5. RDB经常使用配置总结

下面是RDB经常使用的配置项，以及默认值；前面介绍过的这里再也不详细介绍。 save m n：bgsave自动触发的条件；若是没有save m n配置，至关于自动的RDB持久化关闭，不过此时仍能够经过其余方式触发 stop-writes-on-bgsave-error yes：当bgsave出现错误时，Redis是否中止执行写命令；设置为yes，则当硬盘出现问题时，能够及时发现，避免数据的大量丢失；设置为no，则Redis无视bgsave的错误继续执行写命令，当对Redis服务器的系统(尤为是硬盘)使用了监控时，该选项考虑设置为no rdbcompression yes：是否开启RDB文件压缩 rdbchecksum yes：是否开启RDB文件的校验，在写入文件和读取文件时都起做用；关闭checksum在写入文件和启动文件时大约能带来10%的性能提高，可是数据损坏时没法发现 dbfilename dump.rdb：RDB文件名 dir ./：RDB文件和AOF文件所在目录 接下来一篇继续介绍更重要的AOF