Redis系列十二：Redis高可用之持久化

一、Redis高可用概述

在Redis语境中，高可用的含义：除了保证提供正常服务(如主从分离、快速容灾技术)，还需要考虑数据容量的扩展、数据安全不会丢失等。

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

• 持久化：持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。

• 复制：复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。

• 哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。

• 集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

接下来会主要介绍redis的高可用，本节介绍redis的持久化部分。

二、Redis 持久化概述

redis持久化作用：将内存中的数据同步到磁盘来保证持久化，持久化可以避免因进程退出而造成数据丢失。当下次Redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。

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

三、RDB持久化

1、RDB持久化方式

RDB持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发两种方式；

手动触发

手动触发有save和bgsave两命令

a、save命令：

阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它

b、bgsave命令：

redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave;

bgsave运行流程

 

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

自动触发

a、配置save m n

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

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

b、其他自动触发机制

除了save m n 以外，还有一些其他情况会触发bgsave：

• 在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点
• 执行shutdown命令时，自动执行rdb持久化。

2、RDB文件操作

a、存储路径

RDB文件的存储路径既可以在启动前配置，也可以通过命令动态设定。
配置：dir配置指定目录，dbfilename指定文件名。默认是Redis根目录下的dump.rdb文件。
命令：可以用命令动态设置rdb文件路径和文件名。
设置路径：config set dir {newdir}

config set dir /usr/local //设置rdb文件保存路径为usr/local

设置文件名：config set dbfilename {newFileName}

config set dbfilename dump.rdb

b、恢复或启动时加载

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

3、优缺点

优点：

a、压缩后的二进制文，适用于备份、全量复制，用于灾难恢复
b、加载RDB恢复数据远快于AOF方式

缺点：

a、无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
b、保存后的二进制文件，存在老版本不兼容新版本rdb文件的问题

四、AOF持久化

AOF持久化(即Append Only File持久化)，是将Redis执行的每次写命令记录到单独的日志文件中（有点像MySQL的binlog）；当Redis重启时再次执行AOF文件中的命令来恢复数据。与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

1、开启AOF持久化

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置：

appendonly yes (默认不开启，为no)

默认文件名：appendfilename “appendonly.aof”

2、AOF持久化流程

1. 所有的写入命令(set hset)会append追加到aof_buf缓冲区中。
2. AOF缓冲区向硬盘做sync同步。
3. 随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩的目的。
4. 当redis服务重启，可load加载AOF文件进行恢复。

3、关于文件重写

a、注意

• 文件重写能减小AOF文件大小，也能减少数据恢复的时间。
• AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作!
• 对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；

b、文件重写之所以能够压缩AOF文件，原因在于：

• • 过期的数据不再写入文件
  • 无效的命令不再写入文件：如有些数据被重复设值(set mykey v1, set mykey v2)、有些数据被删除了(sadd myset v1, del myset)等等
  • 多条命令可以合并为一个：如sadd myset v1, sadd myset v2, sadd myset v3可以合并为sadd myset v1 v2 v3。不过为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset类型的key，并不一定只使用一条命令；而是以某个常量为界将命令拆分为多条。这个常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定义，不可更改，3.0版本中值是64。

c、文件重写的流程（了解即可）

注意：

 

对照上图，文件重写的流程如下：
1 ) Redis父进程首先判断当前是否存在正在执行 bgsave/bgrewriteaof的子进程，如果存在则bgrewriteaof命令直接返回，如果存在bgsave命令则等bgsave执行完成后再执行。这个主要是基于性能方面的考虑。

2 ) 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。

3.1) 父进程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。

3.2) 由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区(图中的aof_rewrite_buf)保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。

子进程根据内存快照，按照命令合并规则写入到新的AOF文件。
5.1) 子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。

5.2) 父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。

5.3) 使用新的AOF文件替换老文件，完成AOF重写。

3、AOF如何恢复？

appendonly yes           //启用aof持久化方式
# appendfsync always //每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec //每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐
# appendfsync no         //完全依赖os，性能最好,持久化没保证（操作系统自身的同步）
no-appendfsync-on-rewrite  yes  //正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100  //aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb   //aof文件,至少超过64M时,重写

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写，即bgrewriteaof操作（可以直接调用bgrewriteaof指令手动触发文件重写）。

5、AOF持久化的优缺点

与RDB持久化相对应，AOF的优缺点如下
优点：支持秒级持久化、兼容性好。
缺点：文件大、恢复速度慢、对性能影响大。

五、redis重启时加载AOF与RDB的顺序

 

• • 重写由父进程fork子进程进行；
  • 重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。

   

  4、AOF常用配置总结

  1. • 设置appendonly yes；
     • 将appendonly.aof放到dir参数指定的目录；
     • 启动Redis，Redis会自动加载appendonly.aof文件。
  1. 当AOF和RDB文件同时存在时，优先加载AOF
  2. 若关闭了AOF，加载RDB文件
  3. 加载AOF/RDB成功，redis重启成功
  4. AOF/RDB存在错误，启动失败打印错误信息