redis持久化机制

0 概述

目前redis的持久化主要有两大机制，即AOF（Append Only File）日志和RDB快速.

1 AOF

写入时机：写后日志即Redis 是先执行命令，把数据写入内存，然后才记录日志；这个和mysql数据WAL日志技术恰恰相反。redis这种写后日志策略可以避免错误的命令写入、不会阻塞写操作。
记录哪些内容：主要记录写操作，如set 命令，和一些设置相关的比如select index（选择相应的库用的）

写入日志格式: 以set testKey testValue;为例 AOF 文件记录格式如下：

*3  ## 表示这个命令有3部分组成，每部分都是由“$+数字”开头，这个命令有三部分$3 开头，$7开头，$10开头
$3 ## 表示set命令有3个字节
set
$7
testKey
$10
testValue;

redis.config

默认没有开启
appendonly no

几种刷盘策略

• Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；其优点是可靠性高，缺点是写入性能有损耗
• Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘;(默认配置)，是一种取舍，宕机会丢失1s内存数据1
• No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

# appendfsync always
appendfsync everysec
# appendfsync no

从上面写入日志格式看出，整个日志日志会越来越大，而且有很多无效操作（比如对一个key反复的写多次，最终会以最后一次写入）对整个恢复时间也会变长。这个时候AOF重写就登场了。
重写机制：重写过程由后台子进程bgrewriteaof来完成，这也是为了避免阻塞主线程，导致数据库性能下降。具体重写过程如下图所示，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志（AOF重写一个新文件）。主线程新写入的数据也会同时写入重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我们就可以用新的 AOF 文件替代旧文件了。
备注：fork子进程时，子进程是会拷贝父进程的页表，即虚实映射关系，而不会拷贝物理内存。子进程复制了父进程页表，也能共享访问父进程的内存数据了，此时，类似于有了父进程的所有内存数据。如果主进程发生写入，会发生写实复制。

重写的触发条件：
配置，系统自动触发，或者手动执行bgrewriteaof命令触发

//文件大小大于64M，且比上一次增加100%
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

2 RDB

RDB（redis DataBase）和AOF相比，RDB记录的是某一时刻的内存快照并不是操作命令。所以在恢复时候可以直接把RDB文件读入内存完成恢复。
范围：为所有的内存数据做快照。
触发机制：Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。save会阻塞主线程，bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。配置文件配置，默认不开启RDB快照，如下面所示。

# save 3600 1   3600秒期间发生1次变化，就触发bgsave
# save 300 100
# save 60 10000

写入机制：bgsave 命令会触发主线程fork生成bgsave子进程，子进程共享主线程的所有内存数据，这个时候子进程可以读取内存数据，并他们写入RDB文件中。采用写时复制的方式，这样不阻塞主线程正常写操作，如下图所示

不难发现如果采用RDB作为恢复，很容易丢失数据，如果频繁地执行全量快照，也会带来频繁的写磁盘，频繁fork子进程带来性能损耗等问题，fork过程也会阻塞主线程。基于此Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法：内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。