纸上得来终觉浅，绝知此事要躬行！

Redis的持久化有两种，RDB和AOF。

RDB持久化

RDB持久化是把当前进程数据生成快照保存到硬盘的过程。

（1）触发机制

RDB持久化的触发方式有两种，分别是手动触发和自动触发。这个很好理解，手动触发，就是指人为使用命令执行RDB持久化，而自动触发就是当Redis进程满足某个条件后，自动执行RDB持久化。

手动触发分别对应save命令和bgsave命令：

• save命令：会阻塞当前Redis服务器，直到save执行完毕，也就是RDB持久化完毕。如果Redis实例的内存比较大，那么阻塞时间会比较长，一般线上不使用；
• bgsave命令：save的升级版本，bg表示后台运行。使用此命令后，Redis进程会执行fork操作，创建一个子进程，由子进程执行RDB持久化工作，而主进程仍然可以接受客户端的命令。使用此命令并不是说不会阻塞Redis服务，而是阻塞只发生在执行fork操作创建子进程这一阶段，这个操作时间一般都很短。显然，bgsave命令是针对save命令的一个优化升级版本，所以Redis内部涉及到的RDB操作都是采用bgsave命令方式，已经废弃save命令。也建议大家使用bgsave命令。

自动触发分别有如下几个场景：

• save配置：打开Redis的配置文件，可以看到如下一段内容

# 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
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

当900秒内至少1条记录被修改或者300秒内至少10条记录被修改或者60秒内至少10000条记录被修改时，自动触发RDB持久化；

• 从节点执行全量复制操作，主节点自动执行bgsave命令生成RDB文件发送给从节点；
• 执行debug reload命令重新加载Redis时，也会自动触发save操作；
• 默认情况下执行shutdown命令时，如果没有开启AOF持久化则自动执行bgsave；

（2）触发流程

bgsave是主流的触发RDB持久化的方式，我们来了解一下它的工作流程：

1. 执行bgsave命令后，Redis主进程首先会判断当前是否存在正在执行的子进程，如果存在，则直接返回；
2. 父进程执行fork命令，创建子进程，在此期间，主进程会阻塞，知道fork命令执行完毕。通过info status命令查看latest_fork_use选项，可以知道最近一次fork操作的耗时，单位是微妙，从单位可以看出，fork的耗时是非常短的；
3. 主进程执行完fork命令后，主进程会接收到bgsave命令的处理信息“Background saving started”，表示bgsave命令执行完毕（不代表RDB生成完毕），主进程不再阻塞，可以继续响应客户端的其他命令；
4. 子进程创建RDB文件，根据主进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项；
5. 子进程发送信号给主进程表示完成，主进程更新统计信息，具体见info Persistence下的rdb_*相关选项。

（3）RDB文件的处理

生成的RDB文件，在哪可以找到它？它有多大？会不会有问题？对于这些问题，我们一个个解答。

• 保存：RDB文件的存储位置，在配置文件中指定

# The filename where to dump the DB
dbfilename dump.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

这里的两个配置，dir表示RDB文件的存储位置，dbfilename表示生成的RDB文件的名称。配置文件大家都熟悉，修改配置后，需要重启才能生效，那能不能不重启设置呢？答案是可以，通过命令config set dir {newDir}和config set dbfilename {newFileName}可以在运行期动态指定，当下次RDB持久化时就会保存到新的目录，使用新的文件名称；

• 压缩：如果Redis实例的内存比较大，那么生成的RDB文件也会比较大，Redis默认是开启压缩的，同样在配置文件中

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件会远小于内存大小。压缩默认是开启的，和dir、dbfilename一样，也可以通过config set rdbcompression {yes|no}动态修改。

虽然压缩可以大幅度降低文件的大小，但是压缩会消耗一部分CPU，如果想要节省CPU的消耗，可以考虑关闭。但是，不压缩的文件大小会比较大，在主节点发送给从节点时，由于文件过大会消耗更多的带宽，需要根据实际情况考虑是否开启，一般线上建议开启。

• 校验：关于校验，在配置文件里有这么一段

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes

这是一个关于校验的配置项。版本5之后生成的RDB会在结尾增加CRC64校验和，使格式更加严谨不容易损坏的同时，在保存和加载的时候，会有10%的性能损耗。如果没有开启这个配置，校验和默认是0，当加载的时候，如果校验和是0，则跳过检查。

Redis提供了一个redis-check-dump工具，用于检测RDB文件并获取相应的错误报告，如果RDB文件损坏，启动时会有相应的提示，可以使用该工具进行检测并获取检测结果。

（4）RDB持久化的优缺点

优点：

1. 非常适合作为备份存在，它本身就代表Redis在某个时间点上的数据快照，而且是紧凑压缩的二进制文件，可以定期执行备份，用于灾难恢复；
2. Redis加载RDB文件恢复数据远比加载AOF文件要快，因为AOF是命令集合，而RDB是数据快照；

缺点：

1. 不能做到实时持久化，这一点非常明显，save会阻塞服务，不适合在实例运行期间持久化，而bgsave需要fork子进程持久化，不仅fork子进程后需要继续提供服务，而且fork子进程是一个重量级操作，不能频繁执行，成本太高；
2. RDB文件使用特定的二进制格式保存，不同的版本间可能存在兼容问题；

关于AOF持久化，请查看Redis持久化之AOF持久化

欢迎评论、转发、收藏~