Java架构师-5分钟带你深刻理解Redis的持久化方式及其原理

Redis 提供了两种持久化方式，一种是基于快照形式的 RDB，另外一种是基于日志形式的 AOF，每种方式都有本身的优缺点，本文将介绍 Redis 这两种持久化方式，但愿阅读本文后你对 Redis 的这两种持久化方式有更加全面、清晰的认识。

RDB 快照方式持久化

先从 RDB 快照方式聊起，RDB 是 Redis 默认开启的持久化方式，并不须要咱们单独开启，先来看看跟 RDB 相关的配置信息：

################################ SNAPSHOTTING  ################################ 
# 
# Save the DB on disk: 
# 
#   save <seconds> <changes> 
# 
#   Will save the DB if both the given number of seconds and the given 
#   number of write operations against the DB occurred. 
# 
#   In the example below the behaviour will be to save: 
#   after 900 sec (15 min) if at least 1 key changed 
#   after 300 sec (5 min) if at least 10 keys changed 
#   after 60 sec if at least 10000 keys changed 
#   save "" 
# 自动生成快照的触发机制 中间的是时间，单位秒，后面的是变动数据 60 秒变动 10000 条数据则自动生成快照 
save 900 1 
save 300 10 
save 60 10000 
 
# 生成快照失败时，主线程是否中止写入 
stop-writes-on-bgsave-error yes 
 
# 是否采用压缩算法存储 
rdbcompression yes 
 
# 数据恢复时是否检测 RDB文件有效性 
rdbchecksum yes 
 
# The filename where to dump the DB 
# RDB 快照生成的文件名称 
dbfilename dump.rdb 
 
# 快照生成的路径 AOF 也是存放在这个路径下面 
dir .

小编最近将收集的Java程序员进阶架构师的资料作了一些整理，资料适合1-5年的Java开发者，如今分享给每一位从事Java的朋友。须要的朋友能够今后连接里面获取 https://w.url.cn/s/AnCuiWo

关于 RDB 相关配置信息很少，须要咱们调整的就更少了，咱们只须要根据本身的业务量修改生成快照的机制和文件存放路径便可。

RDB 有两种持久化方式：手动触发 和 自动触发，手动触发使用如下两个命令：

save：会阻塞当前 Redis 服务器响应其余命令，直到 RDB 快照生成完成为止，对于内存 比较大的实例会形成长时间阻塞，因此线上环境不建议使用。

bgsave：Redis 主进程会 fork 一个子进程，RDB 快照生成有子进程来负责，完成以后，子进程自动结束，bgsave 只会在 fork 子进程的时候短暂的阻塞，这个过程是很是短的，因此推荐使用该命令来手动触发。

除了执行命令手动触发以外，Redis 内部还存在自动触发 RDB 的持久化机制，在如下几种状况下 Redis 会自动触发 RDB 持久化：

在配置中配置了 save 相关配置信息，如咱们上面配置文件中的 save 60 10000 ，也能够把它归类为“save m n”格式的配置，表示 m 秒内数据集存在 n 次修改时，会自动触发 bgsave。

在主从状况下，若是从节点执行全量复制操做，主节点自动执行 bgsave 生成 RDB 文件并发送给从节点。

执行 debug reload 命令从新加载 Redis 时，也会自动触发 save 操做。

默认状况下执行 shutdown 命令时，若是没有开启 AOF 持久化功能则自动执行 bgsave。

上面就是 RDB 持久化的方式，能够看出 save 命令使用的比较少，大多数状况下使用的都是 bgsave 命令，因此这个 bgsave 命令仍是有一些东西，那接下来咱们就一块儿看看 bgsave 背后的原理，先从流程图开始入手：

bgsave 命令大概有如下几个步骤：

一、执行 bgsave 命令，Redis 主进程判断当前是否存在正在执行的 RDB/AOF 子进程，若是存在， bgsave 命令直接返回不在往下执行。

二、父进程执行 fork 操做建立子进程，fork 操做过程当中父进程会阻塞，fork 完成后父进程将不在阻塞能够接受其余命令。

三、子进程建立新的 RDB 文件，基于父进程当前内存数据生成临时快照文件，完成后用新的 RDB 文件替换原有的 RDB 文件，而且给父进程发送 RDB 快照生成完毕通知。

上面就是 bgsave 命令背后的一些内容，RDB 的内容就差很少了，咱们一块儿来总结 RDB 持久化的优缺点，RDB 方式的优势：

RDB 快照是某一时刻 Redis 节点内存数据，很是适合作备份，上传到远程服务器或者文件系统中，用于容灾备份。

数据恢复时 RDB 要远远快于 AOF。

有优势一样存在缺点，RDB 的缺点有：

RDB 持久化方式数据没办法作到实时持久化/秒级持久化。咱们已经知道了 bgsave 命令每次运行都要执行 fork 操做建立子进程，属于重量级操做，频繁执行成本太高。

RDB 文件使用特定二进制格式保存，Redis 版本演进过程当中有多个格式 的 RDB 版本，存在老版本 Redis 服务没法兼容新版 RDB 格式的问题。

若是咱们对数据要求比较高，每一秒的数据都不能丢，RDB 持久化方式确定是不可以知足要求的，那 Redis 有没有办法知足呢，答案是有的，那就是接下来的 AOF 持久化方式。

AOF 文件持久化方式

Redis 默认并无开启 AOF 持久化方式，须要咱们自行开启，在 redis.conf 配置文件中将 appendonly no 调整为 appendonly yes，这样就开启了 AOF 持久化，与 RDB 不一样的是 AOF 是以记录操做命令的形式来持久化数据的，咱们能够查看如下 AOF 的持久化文件 appendonly.aof。

*2 
$6 
SELECT 
$1 
0 
*3 
$3 
set 
$6 
mykey1 
$6 
你好 
*3 
$3 
set 
$4 
key2 
$5 
hello 
*1 
$8

大概就是长这样的，具体的你能够查看你 Redis 服务器上的 appendonly.aof 配置文件，这也意味着咱们能够在 appendonly.aof 文件中国修改值，等 Redis 重启时将会加载修改以后的值。看似一些简单的操做命令，其实从命令到 appendonly.aof 这个过程当中很是有学问的，下面时 AOF 持久化流程图：

在 AOF 持久化过程当中有两个很是重要的操做：一个是将操做命令追加到 AOF_BUF 缓存区，另外一个是 AOF_buf 缓存区数据同步到 AOF 文件，接下来咱们详细聊一聊这两个操做：

一、为何要将命令写入到 aof_buf 缓存区而不是直接写入到 aof 文件?

咱们知道 Redis 是单线程响应，若是每次写入 AOF 命令都直接追加到磁盘上的 AOF 文件中，这样频繁的 IO 开销，Redis 的性能就完成取决于你的机器硬件了，为了提高 Redis 的响应效率就添加了一层 aof_buf 缓存层， 利用的是操做系统的 cache 技术，这样就提高了 Redis 的性能，虽然这样性能是解决了，可是同时也引入了一个问题，aof_buf 缓存区数据如何同步到 AOF 文件呢?由谁同步呢?这就是咱们接下来要聊的一个操做：fsync 操做。

二、aof_buf 缓存区数据如何同步到 aof 文件中?

aof_buf 缓存区数据写入到 aof 文件是有 linux 系统去完成的，因为 Linux 系统调度机制周期比较长，若是系统故障宕机了，意味着一个周期内的数据将所有丢失，这不是咱们想要的，因此 Linux 提供了一个 fsync 命令，fsync 是针对单个文件操做(好比这里的 AOF 文件)，作强制硬盘同步，fsync 将阻塞直到写入硬盘完成后返回，保证了数据持久化，正是因为有这个命令，因此 redis 提供了配置项让咱们自行决定什么时候进行磁盘同步，redis 在 redis.conf 中提供了appendfsync 配置项，有以下三个选项：

# appendfsync always 
appendfsync everysec 
# appendfsync no

always：每次有写入命令都进行缓存区与磁盘数据同步，这样保证不会有数据丢失，可是这样会致使 redis 的吞吐量大大降低，降低到每秒只能支持几百的 TPS ，这违背了 redis 的设计，因此不推荐使用这种方式

everysec：这是 redis 默认的同步机制，虽然每秒同步一次数据，看上去时间也很快的，可是它对 redis 的吞吐量没有任何影响，每秒同步一次的话意味着最坏的状况下咱们只会丢失 1 秒的数据， 推荐使用这种同步机制，兼顾性能和数据安全

no：不作任何处理，缓存区与 aof 文件同步交给系统去调度，操做系统同步调度的周期不固定，最长会有 30 秒的间隔，这样出故障了就会丢失比较多的数据。 这就是三种磁盘同步策略，可是你有没有注意到一个问题，AOF 文件都是追加的，随着服务器的运行 AOF 文件会愈来愈大，体积过大的 AOF 文件对 redis 服务器甚至是主机都会有影响，并且在 Redis 重启时加载过大的 AOF 文件须要过多的时间，这些都是不友好的，那 Redis 是如何解决这个问题的呢?Redis 引入了重写机制来解决 AOF 文件过大的问题。

三、Redis 是如何进行 AOF 文件重写的?

Redis AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程，重写以后的 AOF 文件会比旧的 AOF 文件占更小的体积，这是由如下几个缘由致使的：

进程内已经超时的数据再也不写入文件

旧的 AOF 文件含有无效命令，如 del key一、hdel key二、srem keys、set a1十一、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保 留最终数据的写入命令

多条写命令能够合并为一个，如：lpush list a、lpush list b、lpush list c能够转化为：lpush list a b c。为了防止单条命令过大形成客户端缓冲区溢 出，对于 list、set、hash、zset 等类型操做，以 64 个元素为界拆分为多条。

重写以后的 AOF 文件体积更小了，不但可以节约磁盘空间，更重要的是在 Redis 数据恢复时，更小体积的 AOF 文件加载时间更短。AOF 文件重写跟 RDB 持久化同样分为手动触发和自动触发，手动触发直接调用 bgrewriteaof 命令就行了，咱们后面会详细聊一聊这个命令，自动触发就须要咱们在 redis.conf 中修改如下几个配置：

auto-aof-rewrite-percentage 100 
auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-percentage：表明当前 AOF文件空间 (aof_current_size)和上一次重写后 AOF 文件空间(aof_base_size)的比值，默认是 100%，也就是同样大的时候

auto-aof-rewrite-min-size：表示运行 AOF 重写时 AOF 文件最小体积，默认为 64MB，也就是说 AOF 文件最小为 64MB 才有可能触发重写。 知足了这两个条件，Redis 就会自动触发 AOF 文件重写，AOF 文件重写的细节跟 RDB 持久化生成快照有点相似，下面是 AOF 文件重写流程图：

AOF 文件重写也是交给子进程来完成，跟 RDB 生成快照很像，AOF 文件重写在重写期间创建了一个 aof_rewrite_buf 缓存区来保存重写期间主进程响应的命令，等新的 AOF 文件重写完成后，将这部分文件同步到新的 AOF 文件中，最后用新的 AOF 文件替换掉旧的 AOF 文件。须要注意的是在重写期间，旧的 AOF 文件依然会进行磁盘同步，这样作的目的是防止重写失败致使数据丢失。

Redis 持久化数据恢复

咱们知道 Redis 是基于内存的，全部的数据都存放在内存中，因为机器宕机或者其余因素重启了就会致使咱们的数据所有丢失，这也就是要作持久化的缘由，当服务器重启时，Redis 会从持久化文件中加载数据，这样咱们的数据就恢复到了重启前的数据，在数据恢复这一块Redis 是如何实现的?咱们先来看看数据恢复的流程图：

Redis 的数据恢复流程比较简单，优先恢复的是 AOF 文件，若是 AOF 文件不存在时则尝试加载 RDB 文件，为何 RDB 的恢复速度比 AOF 文件快，可是仍是会优先加载 AOF 文件呢?我我的认为是 AOF 文件数据更全面而且 AOF 兼容性比 RDB 强，须要注意的是当存在 RDB/AOF 时，若是数据加载不成功，Redis 服务启动会失败。