为了防止数据丢失以及服务重启时能够恢复数据，Redis提供了两种主要的持久化机制，RDB和AOF。
一、RDB
RDB就是Redis DataBase的缩写，意为快照/内存快照。RDB是把当前进程数据生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的数据要早于或等于内存中的值。
1.触发方式
触发RDB持久化的方式有2种，分别是自动触发和手动触发。
（1）手动触发
手动触发对应两个命令，save和bgsave。
- save
阻塞当前Redis服务器，直到RDB过程完成为止，如果内存比较大会造成长时间阻塞，线上环境不建议使用。 - bgsave
Redis进程执行fork操作创建子进程，RDB持久化操作由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。
bgsave流程
具体流程说明如下：
- Redis客户端手动执行bgsave命令或自动触发bgsave命令;
- Redis主进程会判断是否存在子进程，如果存在直接返回;
- 如果不存在子进程，Redis主进程将会fork一个新的子进程进行数据持久化操作，fork过程是阻塞的，fork操作完后主进程即可执行其他操作;
- 子进程会将数据先写到临时的RDB文件中，待快照数据写入完成后再原子替换旧的RDB文件;
- 子进程操作完成后发送信号通知主进程RDB持久化完成，主进程更新相关的统计信息（info Persitence下的rdb_*相关选项）;
（2）自动触发
以下4种情况会自动触发RDB持久化
- redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；
- 主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点；
- 执行debug reload命令重新加载redis时也会触发bgsave操作；
- 默认情况下执行shutdown命令时，如果没有开启aof持久化，那么也会触发bgsave操作；
2.深入理解RDB
问题一：
由于生产环境中我们为Redis开辟的内存区域都比较大（例如6GB），那么将内存中的数据同步到硬盘的过程可能就会持续比较长的时间，而实际情况是这段时间Redis服务一般都会收到数据写操作请求。那么如何保证数据一致性呢？
RDB中的核心思路是Copy-on-Write，来保证在进行快照操作的这段时间，需要压缩写入磁盘上的数据在内存中不会发生变化。在正常的快照操作中，一方面Redis主进程会fork一个新的快照进程专门来做这个事情，这样保证了Redis服务不会停止对客户端包括写请求在内的任何响应。另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域，待快照操作结束后才会同步到原来的内存区域。
举个例子：如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。
rdb
问题二：
在进行快照操作的这段时间，如果发生服务崩溃怎么办？
很简单，在没有将数据全部写入到磁盘前，这次快照操作都不算成功。如果出现了服务崩溃的情况，将以上一次完整的RDB快照文件作为恢复内存数据的参考。也就是说，在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行数据操作，待操作成功后才会用这个临时文件替换掉上一次的备份。
二、AOF
Redis是“写后”日志，Redis先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令是以文本形式保存。PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。
AOF日志采用写后日志，即先写内存，后写日志。
AOF
AOF日志记录Redis的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。
Redis提供了三种写回策略：
AOF日志记录
关于redis.conf中AOF配置如下
# appendonly参数开启AOF持久化
appendonly no
# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./
# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 加载aof出错如何处理
aof-load-truncated yes
# 文件重写策略
aof-rewrite-incremental-fsync yes
操作流程如下：
- 主进程fork出子进程重写aof日志（bgrewriteaof，解决aof文件过大的问题）
- 子进程重写日志完成后，主进程追加aof日志缓冲
- 替换日志文件
image.png
三、RDB和AOF的优缺点对比
- RDB适合大规模的数据恢复，恢复速度快。AOF恢复速度慢（AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。），如果两者都开启，redis重启的时候会优先载入AOF文件来恢复原始的数据。
- RDB数据的完整性和一致性不高，AOF数据的完整性和一致性较好。
加载顺序
RDB和AOF的混合使用
RDB内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。
这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。
如下图所示，T1 和 T2 时刻的修改，用 AOF 日志记录，等到第二次做全量快照时，就可以清空 AOF 日志，因为此时的修改都已经记录到快照中了，恢复时就不再用日志了。
image.png
这个方法既能享受到 RDB 文件快速恢复的好处，又能享受到 AOF 只记录操作命令的简单优势, 实际环境中用的很多。
网友评论