redis:从入门到入土:8.RDB和AOF

众所周知,Redis有两种持久化方案: RDB持久化,AOF持久化;

一.RDB持久化

1.定义

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。即在指定目录下生成一个dump.rdb文件, 当Redis实例故障重启后，从磁盘读取快照文件，恢复数据.快照文件称为RDB文件，默认是保存在当前运行目录。

将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可恢复数据。

2.执行时机

RDB持久化在四种情况下会执行：

• 执行save命令
• 执行bgsave命令
• Redis停机时
• 触发RDB条件时

1）save命令

执行下面的命令，可以立即执行一次RDB：

save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。

2）bgsave命令

下面的命令可以异步执行RDB：

这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。

3）停机时

Redis停机时会执行一次save命令，实现RDB持久化。

4）触发RDB条件

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

# 900秒内，如果至少有1个key被修改，则执行bgsave ，
# 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000 

RDB的其它配置也可以在redis.conf文件中设置：

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./ 

3.RDB原理

bgsave开始时会异步fork主进程得到子进程，这个过程对主进程几乎是零阻塞,子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

异步fork过程中,主进程不会直接操作物理内存,操作虚拟内存,维护一个页表的映射关系,类似map来进行操作,fork 复制页表,实现内存共享;

如果主进程需要写操作,会拷贝数据副本,映射关系重新指向;

fork采用的是copy-on-write [写入时复制] 技术：

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作。
  

4.RDB 的优缺点

优点：

• 适合大规模的数据恢复。
• 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：

• RDB执行时间间隔长,两次RDB之间写入数据由丢失的风险;
• fork子进程、压缩、写出RDB文件都比较耗时;
• 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
  所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

5.小结

1.RDB方式bgsave的基本流程？

• fork主进程得到一个子进程，共享内存空间
• 子进程读取内存数据并写入新的RDB文件
• 用新RDB文件替换旧的RDB文件

2.RDB会在什么时候执行？save 60 1000代表什么含义？

• 默认是服务停止时
• 代表60秒内至少执行1000次修改则触发RDB

3.RDB的缺点？

• RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
• fork子进程、压缩、写出RDB文件都比较耗时

二.RDB持久化

1.AOF原理

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

Redis是“写后”日志，Redis先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令是以文本形式保存。

PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。

2.AOF配置

肯定不能每执行一条写入命令就记录到文件中，那会严重拖垮redis性能！redis存在一个缓冲区，然后把要记录的命令先临时保存在这里，然后再择机写入文件,这个临时缓冲区叫做aof_buf。

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配：
appendfsync always
表示每执行一次写命令，立即记录到AOF文件,即每操作刷盘;

appendfsync everysec
写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案,即每秒刷盘

appendfsync no
写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

为什么要进行刷盘操作?
操作系统也有个缓存区，写的数据被他缓存起来了，没有写入到文件中去;

三种策略对比：

项目	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高,几乎不丢失数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失一秒数据
no	操作系统控制	性能最好	可靠性较差,可能丢失大量数据

3.AOF文件重写

3.1 定义

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

如图，AOF原本有三个命令，但是set num 123 和 set num 666都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。

所以重写命令后，AOF文件内容就是：mset name jack num 666

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb 

3.2 步骤

• 主线程fork出子进程重写aof日志
• 子进程重写日志完成后，主线程追加aof日志缓冲
• 替换日志文件

3.3 问题

1.AOF重写会阻塞吗？
AOF重写过程是由后台进程bgrewriteaof来完成的。
主线程fork出后台的bgrewriteaof子进程，fork会把主线程的内存拷贝一份给bgrewriteaof子进程，这里面就包含了数据库的最新数据。

然后，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

所以aof在重写时，在fork进程时是会阻塞住主线程的。

2.AOF日志何时会重写？
有两个配置项控制AOF重写的触发：

auto-aof-rewrite-min-size:表示运行AOF重写时文件的最小大小，默认为64MB。

auto-aof-rewrite-percentage:这个值的计算方式是，当前aof文件大小和上一次重写后aof文件大小的差值，再除以上一次重写后aof文件大小。也就是当前aof文件比上一次重写后aof文件的增量大小，和上一次重写后aof文件大小的比值。

4.AOF优缺点

优点:

• 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。
• 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过 redis-check-aof 工具来帮助我们解决数据一致性的问题。
• 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
• AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

缺点:

• 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。
• 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

5.RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

三:RDB和AOF混合方式

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。

如下图所示，T1 和 T2 时刻的修改，用 AOF 日志记录，等到第二次做全量快照时，就可以清空 AOF 日志，因为此时的修改都已经记录到快照中了，恢复时就不再用日志了。

这个方法既能享受到 RDB 文件快速恢复的好处，又能享受到 AOF 只记录操作命令的简单优势, 实际环境中用的很多。

四:数据恢复

其实想要从这些文件中恢复数据，只需要重新启动Redis即可。我们还是通过图来了解这个流程：

• redis重启时判断是否开启aof，如果开启了aof，那么就优先加载aof文件；
• 如果aof存在,那么就去加载aof文件，加载成功的话redis重启成功，如果aof文件加载失败，那么会打印日志表示启动失败，此时可以去修复aof文件后重新启动;
• 若aof文件不存在，那么redis就会转而去加载rdb文件，如果rdb文件不存在，redis直接启动成功;
• 如果rdb文件存在就会去加载rdb文件恢复数据，如加载失败则打印日志提示启动失败，如加载成功，那么redis重启成功，且使用rdb文件恢复数据；

那么为什么会优先加载AOF呢？
因为AOF保存的数据更完整，通过上面的分析我们知道AOF基本上最多损失1s的数据。

五:性能与实践

通过上面的分析，我们都知道RDB的快照、AOF的重写都需要fork，这是一个重量级操作，会对Redis造成阻塞。因此为了不影响Redis主进程响应，我们需要尽可能降低阻塞。

• 降低fork的频率，比如可以手动来触发RDB生成快照、与AOF重写；
• 控制Redis最大使用内存，防止fork耗时过长；
• 使用更牛逼的硬件；
• 合理配置Linux的内存分配策略，避免因为物理内存不足导致fork失败。

在线上我们到底该怎么做？

• 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据，可以关闭持久化，如果丢失数据可以通过其它途径补回；
• 自己制定策略定期检查Redis的情况，然后可以手动触发备份、重写数据;
• 单机如果部署多个实例，要防止多个机器同时运行持久化、重写操作，防止出现内存、CPU、IO资源竞争，让持久化变为串行；
• 可以加入主从机器，利用一台从机器进行备份处理，其它机器正常响应客户端的命令；
• RDB持久化与AOF持久化可以同时存在，配合使用。

六.总结

• aof 命令集合文件,rdb 数据集合文件
• 故事化的rdb和aof,通俗易懂
• redis持久化详解
• 黑马yyds