【Redis从入门到进阶】第 9 讲：Redis 持久化之 —— RDB

本文已收录于专栏 《Redis从入门到进阶》

专栏前言

   本专栏开启，目的在于帮助大家更好的掌握学习Redis，同时也是为了记录我自己学习Redis的过程，将会从基础的数据类型开始记录，直到一些更多的应用，如缓存击穿还有分布式锁等。希望大家有问题也可以一起沟通，欢迎一起学习，对于专栏内容有错还望您可以及时指点，非常感谢大家 。

PS: AOF见专栏上文：Redis 持久化之 —— AOF

1. RDB的持久化

  上一篇文章我们细讲了AOF日志进行Redis的持久化，今天我们讲另外一种方式——RDB快照持久化，其全程为 Redis Backup file(Redis数据备份文件)。
  快照这个东西，就是记录一瞬间，比如大家出去景区旅游就经常遇到一些帮忙拍快照的小贩。如果大家经常用虚拟机的话也应该知道，它里面就可以通过快照存储，当虚拟机崩的时候回到快照时的存储状态。而RDB也是同理，它可以记录一瞬间的Redis内存数据，记录的是实际的内存数据而非执行命令的日志，当需要恢复数据时，直接把dump.rdb文件读入内存即可，所以RDB的恢复效率要比AOF快得多，它不需要去执行操作指令来恢复数据。

2. RDB 的使用

  我们来学习一下RDB究竟应该如何使用，Redis提供了两个指令来主动生成RDB文件，分别是save和bgsave。它们主要的区别在于是否由主线程来执行生成RDB文件操作：

2.1 save命令

• save命令会直接在主线程生成RDB文件，如果写入RDB的时间太长，就会阻塞主线程。 此时其他客户端的请求就会被阻塞， 在生产环境下，一定要慎用该操作！
  

2.2 bgsave

• bgsave命令会fork一个子进程来生成RDB文件，这样主线程可以继续执行其他客户端到来的命令。当子进程任务完成后，它会退出。
• 

在Redis的config文件中我们也可以更改bgsave命令的配置信息：

save 900 1
save 300 10
save 60 10000
下面表示禁用RDB
save ""

前面的指令表示，900秒内至少用一个key被修改，则执行bgsave，第二个是300秒内至少10次修改则触发，第三条类似。注意虽然指令是写的save，但其实执行的是bgsave。
当然还有一些其他的配置也可以修改

是否压缩，建议不开启，压缩会更消耗CPU，磁盘不值钱
rdbcompression yes
RDB文件名称
dbfilename dump.rdb

  RDB的快照方式是全量快照， 会将「所有数据」都记录到磁盘中，显然这个操作是一个重量级的操作，是非常消耗资源。如果太频繁的进行快照，会对Redis的性能造成极大影响，如果快照的间隔时间太长，一旦服务器宕机丢失的数据又会丢失大量的数据。所以设置多长时间进行一次bgsave，需要我们根据应用的场景来自己平衡。
  一般来说，bgsave是不会阻塞主线程的，但其实fork得到子进程这个操作是会阻塞主线程的（只不过这个操作很快），如果存在意外导致fork执行太久，此时也是有可能阻塞主线程的。

3. 触发快照时机

  除了上述我们讲的save命令和bgsave命令，还有一些情况Redis也会自动触发快照

• 1. 主从复制时，从库全量复制同步主库数据，主库会执行bgsave
• 2. 执行flushall命令清空服务器数据，生产环境慎用
• 3. 执行shutdown命令关闭Redis时，会执行save

4. rdb 文件产生过程

   无论是哪种方式进行快照，rdb文件产生的过程如下：

• 1. 生成临时 rdb 文件，并写入数据
• 2. 完成数据写入后，让临时文件覆盖原rdb文件
• 3. 删除原有rdb文件

5. rdb 文件恢复

  当Redis服务器重新启动时，如果根目录存在文件 dump.rdb，则Redis会自动去加载恢复数据。如果没有dump.rdb，我们需要手动将文件移动根目录下，是否成功加载RDB文件我们在启动日志在查看。

PS：在Redis加载 RDB文件时，主线程处于阻塞状态

6. RDB 与 AOF 混用

  不难发现，虽然RDB恢复数据比AOF快很多，但其快照的频率很难把握。

• 频率太低，一旦宕机丢失的数据过多
• 平吕太高，频繁写磁盘和创建子进程开销很大影响性能

  在我们的Redis 4.0 后，提供了AOF与RDB的混用机制，也叫混合持久化。
开启混合持久化需要在config文化中手动开启

改为 yes 开启混合持久化
aof-use-rdb-preamble yes

  这样有什么好处呢？我们要知道，在子线程进行 bgsave时，主线程仍然会执行其他客户端发来的命令，这时子线程快照存储的是原本的内存数据，所以就会导致数据不一致，想修改只能等下一次bgsave的到来。
  当开启混合持久化后，在AOF重写日志时，fork的子进程会先以RDB的方式写入到AOF文件中，在子进程工程时，主线程处理的命令会存储到重写缓冲区内，当子进程完成RDB方式读入后，会再以AOF方式把重写缓冲区的指令写入到AOF文件中。
  这样操作后，AOF文件前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的 增量数据。
  这样我们可以集成两者的优点，前半部分由于是RDB所以加载很快，后半部分由于是AOF，所以丢失的数据更少。

7. AOF 与 RDB 对比

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次快照之间会丢失数据	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，数据完整性高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO，但重写时占用CPU和大量资源
使用场景	可以容忍数分钟数据丢失，追求更快的启动速度	对数据安全性要求较高