从零开始Redis(七)：Redis持久化

本节将主要介绍redis的持久化机制

首先读者要知道为什么要持久化&＃xff1f;

Redis是内存数据库&＃xff0c;宕机后数据会消失。
Redis重启后快速恢复数据&＃xff0c;要提供持久化机制
Redis有两种持久化方式&＃xff1a;RDB和AOF
注意&＃xff1a;Redis持久化不保证数据的完整性。
当Redis用作DB时&＃xff0c;DB数据要完整&＃xff0c;所以一定要有一个完整的数据源&＃xff08;文件、mysql&＃xff09;
在系统启动时&＃xff0c;从这个完整的数据源中将数据load到Redis中
数据量较小&＃xff0c;不易改变&＃xff0c;比如&＃xff1a;字典库

RDB&＃xff08;Redis DataBase&＃xff09;&＃xff0c;是redis默认的存储方式&＃xff0c;RDB方式是通过快照&＃xff08; snapshotting &＃xff09;完成的。

使用RDB相当于关注这一刻的数据 &＃xff0c;不关注过程

触发快照的方式

1. 符合自定义配置的快照规则
2. 执行save或者bgsave命令
3. 执行flushall命令
4. 执行主从复制操作 (第一次)

配置参数定期执行

在redis.conf中配置&＃xff1a;save 多少秒内 数据变了多少

save "" # 不使用RDB存储 不能主从
save 900 1 # 表示15分钟&＃xff08;900秒钟&＃xff09;内至少1个键被更改则进行快照。
save 300 10 # 表示5分钟&＃xff08;300秒&＃xff09;内至少10个键被更改则进行快照。
save 60 10000 # 表示1分钟内至少10000个键被更改则进行快照。


漏斗设计 提供性能

命令显式触发

在客户端输入bgsave命令。

127.0.0.1:6379> bgsave
Background saving started


RDB执行流程&＃xff08;原理&＃xff09;

1. Redis父进程首先判断&＃xff1a;当前是否在执行save&＃xff0c;或bgsave/bgrewriteaof&＃xff08;aof文件重写命令&＃xff09;的子进程&＃xff0c;如果在执行则bgsave命令直接返回。
2. 父进程执行fork&＃xff08;调用OS函数复制主进程&＃xff09;操作创建子进程&＃xff0c;这个过程中父进程是阻塞的&＃xff0c;Redis不能执行来自客户端的任何命令。
3. 父进程fork后&＃xff0c;bgsave命令返回”Background saving started”信息并不再阻塞父进程&＃xff0c;并可以响应其他命令。
4. 子进程创建RDB文件&＃xff0c;根据父进程内存快照生成临时快照文件&＃xff0c;完成后对原有文件进行原子替换。&＃xff08;RDB始终完整&＃xff09;
5. 子进程发送信号给父进程表示完成&＃xff0c;父进程更新统计信息。
6. 父进程fork子进程后&＃xff0c;继续工作。

RDB文件结构

1、头部5字节固定为“REDIS”字符串
2、4字节“RDB”版本号&＃xff08;不是Redis版本号&＃xff09;&＃xff0c;当前为9&＃xff0c;填充后为0009
3、辅助字段&＃xff0c;以key-value的形式

4、存储数据库号码
5、字典大小
6、过期key
7、主要数据&＃xff0c;以key-value的形式存储
8、结束标志
9、校验和&＃xff0c;就是看文件是否损坏&＃xff0c;或者是否被修改。

RDB的优缺点

优点
RDB是二进制压缩文件&＃xff0c;占用空间小&＃xff0c;便于传输&＃xff08;传给slaver&＃xff09;
主进程fork子进程&＃xff0c;可以最大化Redis性能&＃xff0c;主进程不能太大&＃xff0c;复制过程中主进程阻塞
缺点
不保证数据完整性&＃xff0c;会丢失最后一次快照以后更改的所有数据

AOF&＃xff08;append only file&＃xff09;是Redis的另一种持久化方式。Redis默认情况下是不开启的。开启AOF持久化后
Redis 将所有对数据库进行过写入的命令&＃xff08;及其参数&＃xff09;&＃xff08;RESP&＃xff09;记录到 AOF 文件&＃xff0c; 以此达到记录数据库状态的目的&＃xff0c;这样当Redis重启后只要按顺序回放这些命令就会恢复到原始状态了。
AOF会记录过程&＃xff0c;RDB只管结果

AOF持久化实现

配置 redis.conf

# 可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes
# AOF文件的保存位置和RDB文件的位置相同&＃xff0c;都是通过dir参数设置的。
dir ./
# 默认的文件名是appendonly.aof&＃xff0c;可以通过appendfilename参数修改
appendfilename appendonly.aof


AOF原理

AOF文件中存储的是redis的命令&＃xff0c;同步命令到 AOF 文件的整个过程可以分为三个阶段&＃xff1a;

• 命令传播&＃xff1a;Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。
• 缓存追加&＃xff1a;AOF 程序根据接收到的命令数据&＃xff0c;将命令转换为网络通讯协议的格式&＃xff0c;然后将协议内容追加到服务器的 AOF 缓存中。
• 文件写入和保存&＃xff1a;AOF 缓存中的内容被写入到 AOF 文件末尾&＃xff0c;如果设定的 AOF 保存条件被满足的话&＃xff0c;fsync 函数或者 fdatasync 函数会被调用&＃xff0c;将写入的内容真正地保存到磁盘中。

命令传播

当一个 Redis 客户端需要执行命令时&＃xff0c; 它通过网络连接&＃xff0c; 将协议文本发送给 Redis 服务器。服务器在接到客户端的请求之后&＃xff0c; 它会根据协议文本的内容&＃xff0c; 选择适当的命令函数&＃xff0c; 并将各个参数从字符串文本转换为 Redis 字符串对象&＃xff08; StringObject &＃xff09;。每当命令函数成功执行之后&＃xff0c; 命令参数都会被传播到AOF 程序。

缓存追加

当命令被传播到 AOF 程序之后&＃xff0c; 程序会根据命令以及命令的参数&＃xff0c; 将命令从字符串对象转换回原来的协议文本。协议文本生成之后&＃xff0c; 它会被追加到 redis.h/redisServer 结构的 aof_buf 末尾。
redisServer 结构维持着 Redis 服务器的状态&＃xff0c; aof_buf 域则保存着所有等待写入到 AOF 文件的协议文本&＃xff08;RESP&＃xff09;。

文件写入和保存

每当服务器常规任务函数被执行、 或者事件处理器被执行时&＃xff0c; aof.c/flushAppendOnlyFile 函数都会被调用&＃xff0c; 这个函数执行以下两个工作&＃xff1a;
WRITE&＃xff1a;根据条件&＃xff0c;将 aof_buf 中的缓存写入到 AOF 文件。
SAVE&＃xff1a;根据条件&＃xff0c;调用 fsync 或 fdatasync 函数&＃xff0c;将 AOF 文件保存到磁盘中。

AOF 保存模式

Redis 目前支持三种 AOF 保存模式&＃xff0c;它们分别是&＃xff1a;

• AOF_FSYNC_NO &＃xff1a;不保存。
• AOF_FSYNC_EVERYSEC &＃xff1a;每一秒钟保存一次。&＃xff08;默认&＃xff09;
• AOF_FSYNC_ALWAYS &＃xff1a;每执行一个命令保存一次。&＃xff08;不推荐&＃xff09;
  以下将分别讨论这三种保存模式。

不保存

在这种模式下&＃xff0c; 每次调用 flushAppendOnlyFile 函数&＃xff0c; WRITE 都会被执行&＃xff0c; 但 SAVE 会被略过。
在这种模式下&＃xff0c; SAVE 只会在以下任意一种情况中被执行&＃xff1a;

• Redis 被关闭
• AOF 功能被关闭
• 系统的写缓存被刷新&＃xff08;可能是缓存已经被写满&＃xff0c;或者定期保存操作被执行&＃xff09;

这三种情况下的 SAVE 操作都会引起 Redis 主进程阻塞。

每一秒钟保存一次

在这种模式中&＃xff0c; SAVE 原则上每隔一秒钟就会执行一次&＃xff0c; 因为 SAVE 操作是由后台子线程&＃xff08;fork&＃xff09;调用的&＃xff0c; 所以它不会引起服务器主进程阻塞。

每执行一个命令保存一次

在这种模式下&＃xff0c;每次执行完一个命令之后&＃xff0c; WRITE 和 SAVE 都会被执行。
另外&＃xff0c;因为 SAVE 是由 Redis 主进程执行的&＃xff0c;所以在 SAVE 执行期间&＃xff0c;主进程会被阻塞&＃xff0c;不能接受命令请求。

AOF 保存模式对性能和安全性的影响&＃xff0c;对于三种 AOF 保存模式&＃xff0c; 它们对服务器主进程的阻塞情况如下&＃xff1a;

AOF重写、触发方式、混合持久化

AOF记录数据的变化过程&＃xff0c;越来越大&＃xff0c;需要重写“瘦身”
Redis可以在 AOF体积变得过大时&＃xff0c;自动地在后台&＃xff08;Fork子进程&＃xff09;对 AOF进行重写。重写后的新 AOF文件包含了恢复当前数据集所需的最小命令集合。 所谓的“重写”其实是一个有歧义的词语&＃xff0c; 实际上&＃xff0c;AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取&＃xff0c; 它针对的是数据库中键的当前值。

举例如下&＃xff1a;

set s1 11
set s1 22 ------- > set s1 33
set s1 33
没有优化的&＃xff1a;
set s1 11
set s1 22
set s1 33
优化后&＃xff1a;
set s1 33
lpush list1 1 2 3
lpush list1 4 5 6 -------- > list1 1 2 3 4 5 6
优化后
lpush list1 1 2 3 4 5 6


优化后只保存最新版本的值

Redis 不希望 AOF 重写造成服务器无法处理请求&＃xff0c; 所以 Redis 决定将 AOF 重写程序放到&＃xff08;后台&＃xff09;子进程里执行&＃xff0c; 这样处理的最大好处是&＃xff1a;
1、子进程进行 AOF 重写期间&＃xff0c;主进程可以继续处理命令请求。
2、子进程带有主进程的数据副本&＃xff0c;使用子进程而不是线程&＃xff0c;可以在避免锁的情况下&＃xff0c;保证数据的安全性。
不过&＃xff0c; 使用子进程也有一个问题需要解决&＃xff1a; 因为子进程在进行 AOF 重写期间&＃xff0c; 主进程还需要继续处理
命令&＃xff0c; 而新的命令可能对现有的数据进行修改&＃xff0c; 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。

为了解决这个问题&＃xff0c; Redis 增加了一个 AOF 重写缓存&＃xff0c; 这个缓存在 fork 出子进程之后开始启用&＃xff0c;Redis 主进程在接到新的写命令之后&＃xff0c; 除了会将这个写命令的协议内容追加到现有的 AOF 文件之外&＃xff0c;还会追加到这个缓存中。

重写过程分析&＃xff08;整个重写操作是绝对安全的&＃xff09;&＃xff1a;

Redis 在创建新 AOF 文件的过程中&＃xff0c;会继续将命令追加到现有的 AOF 文件里面&＃xff0c;即使重写过程中发生停机&＃xff0c;现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕&＃xff0c;Redis 就会从旧 AOF 文件切换到新 AOF 文件&＃xff0c;并开始对新 AOF 文件进行追加操作。

当子进程在执行 AOF 重写时&＃xff0c; 主进程需要执行以下三个工作&＃xff1a;

• 处理命令请求。
• 将写命令追加到现有的 AOF 文件中。
• 将写命令追加到 AOF 重写缓存中。

这样一来可以保证&＃xff1a;

• 现有的 AOF 功能会继续执行&＃xff0c;即使在 AOF 重写期间发生停机&＃xff0c;也不会有任何数据丢失。
• 所有对数据库进行修改的命令都会被记录到 AOF 重写缓存中。

当子进程完成 AOF 重写之后&＃xff0c; 它会向父进程发送一个完成信号&＃xff0c; 父进程在接到完成信号之后&＃xff0c; 会调用一个信号处理函数&＃xff0c; 并完成以下工作&＃xff1a;

• 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。
• 对新的 AOF 文件进行改名&＃xff0c;覆盖原有的 AOF 文件。

Redis数据库里的&＃43;AOF重写过程中的命令------->新的AOF文件---->覆盖老的
当步骤 1 执行完毕之后&＃xff0c; 现有 AOF 文件、新 AOF 文件和数据库三者的状态就完全一致了。
当步骤 2 执行完毕之后&＃xff0c; 程序就完成了新旧两个 AOF 文件的交替。
这个信号处理函数执行完毕之后&＃xff0c; 主进程就可以继续像往常一样接受命令请求了。 在整个 AOF 后台重
写过程中&＃xff0c; 只有最后的写入缓存和改名操作会造成主进程阻塞&＃xff0c; 在其他时候&＃xff0c; AOF 后台重写都不会对
主进程造成阻塞&＃xff0c; 这将 AOF 重写对性能造成的影响降到了最低。

以上就是 AOF 后台重写&＃xff0c; 也即是 BGREWRITEAOF 命令(AOF重写)的工作原理。

触发方式

1、配置触发
在redis.conf中配置

# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过&＃xff0c;以启动时aof文件大小为准
auto-aof-rewrite-percentage 100
# 限制允许重写最小aof文件大小&＃xff0c;也就是文件大小小于64mb的时候&＃xff0c;不需要进行优化
auto-aof-rewrite-min-size 64mb


2、执行bgrewriteaof命令

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started


混合持久化

RDB和AOF各有优缺点&＃xff0c;Redis 4.0 开始支持 rdb 和 aof 的混合持久化。如果把混合持久化打开&＃xff0c;aof rewrite 的时候就直接把 rdb 的内容写到 aof 文件开头。
RDB的头&＃43;AOF的身体---->appendonly.aof
开启混合持久化

aof-use-rdb-preamble yes


AOF文件的载入与数据还原

因为AOF文件里面包含了重建数据库状态所需的所有写命令&＃xff0c;所以服务器只要读入并重新执行一遍AOF文件里面保存的写命令&＃xff0c;就可以还原服务器关闭之前的数据库状态

Redis读取AOF文件并还原数据库状态的详细步骤如下&＃xff1a;

1、创建一个不带网络连接的伪客户端&＃xff08;fake client&＃xff09;&＃xff1a;因为Redis的命令只能在客户端上下文中执行&＃xff0c;而载入AOF文件时所使用的命令直接来源于AOF文件而不是网络连接&＃xff0c;所以服 务器使用了一个没有网络连接的伪客户端来执行AOF文件保存的写命令&＃xff0c;伪客户端执行命令 的效果和带网络连接的客户端执行命令的效果完全一样
2、从AOF文件中分析并读取出一条写命令
3、使用伪客户端执行被读出的写命令
4、一直执行步骤2和步骤3&＃xff0c;直到AOF文件中的所有写命令都被处理完毕为止

当完成以上步骤之后&＃xff0c;AOF文件所保存的数据库状态就会被完整地还原出来&＃xff0c;整个过程如下图所示&＃xff1a;

1、RDB存某个时刻的数据快照&＃xff0c;采用二进制压缩存储&＃xff0c;AOF存操作命令&＃xff0c;采用文本存储(混合)
2、RDB性能高、AOF性能较低
3、RDB在配置触发状态会丢失最后一次快照以后更改的所有数据&＃xff0c;AOF设置为每秒保存一次&＃xff0c;则最多丢2秒的数据
4、Redis以主服务器模式运行&＃xff0c;RDB不会保存过期键值对数据&＃xff0c;Redis以从服务器模式运行&＃xff0c;RDB会保存过期键值对&＃xff0c;当主服务器向从服务器同步时&＃xff0c;再清空过期键值对。AOF写入文件时&＃xff0c;对过期的key会追加一条del命令&＃xff0c;当执行AOF重写时&＃xff0c;会忽略过期key和del命令。

应用场景

内存数据库 rdb&＃43;aof 数据不容易丢
缓存服务器 rdb 性能高
不建议 只使用 aof (性能差)
在数据还原时
有rdb&＃43;aof 则还原aof&＃xff0c;因为RDB会造成文件的丢失&＃xff0c;AOF相对数据要完整。
只有rdb&＃xff0c;则还原rdb

本节主要介绍了redis的两种持久化方案