redis知识点(二)--持久化

1. redis高可用概述

在介绍Redis高可用之前，先说明一下在Redis的语境中高可用的含义。

我们知道，在web服务器中，高可用是指服务器可以正常访问的时间，衡量的标准是在多长时间内可以提供正常服务（99.9%、99.99%、99.999% 等等）。但是在Redis语境中，高可用的含义似乎要宽泛一些，除了保证提供正常服务(如主从分离、快速容灾技术)，还需要考虑数据容量的扩展、数据安全不会丢失等。

在Redis中，实现高可用的技术主要包括持久化、复制、哨兵和集群，下面分别说明它们的作用，以及解决了什么样的问题。

1. 持久化：持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
2. 复制：复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
3. 哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。
4. 集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

2. 持久化概述

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

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

下面依次介绍RDB持久化和AOF持久化；由于Redis各个版本之间存在差异，如无特殊说明，以Redis3.0为准

3. RDB持久化

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

1. 触发条件

   1） 手动触发

   save命令和bgsave命令都可以生成RDB文件。

   save命令会阻塞Redis服务器进程，直到RDB文件创建完为止，在Redis服务器阻塞期间，服务器不能处理任何请求

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

此时服务器执行日志如下：

2）自动触发

save m n

自动触发最常见的情况实在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave.

例如，查看redis的默认配置文件(Linux下为根目录下的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记录的是服务器进行了多少次修改，而不是客户端执行了多少修改数据的命令。

lastsave时间戳也是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持久化，如下图所示：

![在这里插入图片描述](https://img-blog.csdnimg.cn/20200703104849768.png)

2. 执行流程

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

图片中的5个步骤所进行的操作如下：

1. redis父进程首先判断：当前是否在执行save,或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。

2. 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，redis不能执行来自客户端的任何命令

3. 父进程fork后,bgsave命令返回"Background saving started"信息并不在阻塞父进程，并可以响应其它命令

4. 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换

5. 子进程发送信号给父进程表示完成，父进程更新统计信息

6. RDB文件是经过压缩的二进制文件，下面介绍关于RDB文件的一些细节。

   存储路径

   RDB文件的存储路径既可以在启动前配置，也可以通过命令动态设定。

   配置：dir配置指定目录，dbfilename指定文件名。默认是redis根目录下的dump.rdb文件

   动态设定：redis启动后也可以动态修改RDB存储路径，在磁盘损害或空间不足时非常有用；执行命令为config set dir {newdir}和config set dbfilename {newFileName}.如下图所示（Windows环境）:

   

​ RDB文件格式

​

其中各个字段的含义如下说明：

redis: 常量，保存着"redis"五个字符

db_version: RDB文件的版本号，注意不是Redis的版本号

SELECTDB 0 pairs:表示一个完整的数据库（0号数据库）；只有当数据库中有键值对时，RDB文件中才会有该数据库信息（上图所示的redis中只有0号和3号数据库有键值对）；如果redis中所有的数据库都没有键值对，则这一部分直接省略。其中：SELECTDB是一个常量，代表后面跟着的是数据库号码；pairs则存储了具体的键值对信息，包括key、value值，及其数据类型、内部编码、过期时间、压缩信息等等。

EOF：常量，标志RDB文件正文内容结束

check_sum:前面所有内容校验和；redis在载入RDB文件时，会计算前面的校验和并与check_sum值比较，判断文件是否损坏

压缩：redis默认词用LZF算法对RDB文件进行压缩。虽然压缩耗时，但是可以大大减小RDB文件体积，因此压缩默认开启；可以通过命令关闭：

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

4. 启动时加载

   RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，redis会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会在redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。

   redis启动日志中可以看到自动载入的执行：

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文件和APF文件所在目录