5.RDB快照

RDB快照：宕机后，Redis如何实现快速恢复？

1.RDB快照如何实现

由于AOF记录的是操作命令，所以用 AOF 方法进行故障恢复的时候，需要逐一把操作日志都执行一遍。如果操作日志非常多，Redis 就会恢复得很缓慢，影响到正常使用。这当然不是理想的结果，所以需要有RDB，对 Redis 来说，它实现类似照片记录效果的方式，就是把某一时刻的状态以文件的形式写到磁盘上，也就是快照。这样一来，即使宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为 RDB 文件，其中，RDB 就是 Redis DataBase 的缩写。

我们还要考虑两个关键问题，拿拍照片来举例子，我们在拍照时，通常要关注两个问题：

• 如何取景？也就是说，我们打算把哪些人、哪些物拍到照片中；

• 在按快门前，要记着提醒朋友不要乱动，否则拍出来的照片就模糊了。

(1)给哪些内存数据做快照？

为了提供所有数据的可靠性保证，它执行的是全量快照，每一次的快照都会替换掉上一次的快照文件。

RDB文件生成的两种方式，分别是 save 和 bgsave：

• save：在主线程中执行，会导致阻塞
• bgsave：主线程复制一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。

(2)快照时数据能修改吗？

可以。如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），那么，这块数据就会被复制一份，生成该数据的副本（键值对 C’）。然后，主线程在这个数据副本上进行修改。同时，bgsave 子进程可以继续把原来的数据（键值对 C）写入 RDB 文件。

2.RDB快照配置详解

在dump.rdb中配置

# 周期性执行条件的设置格式为
# save <seconds> <changes>
# 默认的设置为：
save 900 1
save 300 10
save 60 10000

# 以下设置方式为关闭RDB快照功能
save ""


# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir ./

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

3.AOF和RDB的区别和共存

(1)共存

#aof和rdb混合使用,redis.conf中配置
aof-use-rdb-preamble yes

虽然跟 AOF 相比，快照的恢复速度快，但是，快照的频率不好把握，如果频率太低，两次快照间一旦宕机，就可能有比较多的数据丢失。如果频率太高，又会产生额外开销，那么，还有什么方法既能利用 RDB 的快速恢复，又能以较小的开销做到尽量少丢数据呢？

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

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

⭐总结来说：AOF防止数据丢失，RDB用于快速恢复数据

(2)区别

	AOF日志	RDB快照
文件内容	记录操作命令，追加记录	记录真实数据，替换原文件
配置文件	redis.conf	dump.rdb
写回磁盘策略	Always、EverySec、No	save 秒 写操作/次
恢复速度	慢	快
突然宕机数据丢失量	少，几乎不丢失(Always、EverySec)	多(根据快照频率)
是否阻塞主线程	是，AOF重写不阻塞	否

4.Redis恢复-RDB

是否阻塞主线程 | 是，AOF重写不阻塞 | 否 |

4.Redis恢复-RDB

Redis 数据持久化了，我们还需要通过 AOF 或 RDB 进行恢复，恢复时长取决于 AOF 或 RDB 的大小，如果只有一个 Redis 实例，恢复阶段无法提供服务。