Redis持久化机制

Posted 2022-05-25 lwhsummer

Redis持久化机制

Redis 一共有 2 种持久化方式，分别是 RDB 和 AOF。

RDB持久化

RDB是Redis 默认的持久化方式。它所生成的 RDB 文件是一个压缩的二进制文件，通过该文件可以还原生成 RDB 文件时的数据库状态（数据库状态是指 Redis 服务器的非空数据库以及他们键值对的统称）

RDB 文件的创建

有两个命令可以生成 RDB 文件，一个是 SAVE、另一个是 BGSAVE。
两者的区别在于：前者会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕为止。
而在服务器进程阻塞期间，服务器是不能处理任何命令请求的。
后者则不会阻塞服务器进程，因为是通过 fork 一个子进程，并让其去创建 RDB 文件，而服务器进程（父进程）继续则继续处理命令请求。
当写完数据库状态后，新 RDB 文件就会原子地替换旧的 RDB 文件。

在配置文件中

save 900 1   #900秒内至少有1个key被更改就执行快照
save 300 10  #300内描述至少有10个key被更改就执行快照
save 60 10000  #60秒内至少有10000个key被更改就执行快照

RDB 文件的载入

RDB 文件的载入是在服务器启动时自动执行的，所以没有用于载入的命令，期间阻塞主进程。
只要没有开启 AOF 持久化功能，在启动时检测到有 RDB 文件，就会自动载入。
当服务器有开启 AOF 持久化功能时，服务器将会优先使用 AOF 文件来还原数据库状态。原因是 AOF 文件的更新频率通常比 RDB 文件的更新频率高。

AOF 持久化

RDB 持久化通过保存数据库状态来持久化。而 AOF 与之不同，它是通过保存对数据库的写命令来记录数据库状态。
比如执行了 set key 123,Redis 就会将这条写命令保存到 AOF 文件中。
在服务器下次启动时，就可以通过载入和执行 AOF 文件中保存的命令，来还原服务器关闭前的数据库状态了。
总体流程和 RDB 持久化一样 —— 都是创建一个 xxx 文件、在服务器下次启动时就载入这个文件来还原数据

AOF持久化实现

AOF 持久化功能的实现可以分为 3 个步骤：命令追加、文件写入、文件同步
将写命令追加到 AOF 缓冲区的末尾，接着缓冲区内容写到 AOF 文件，最后 AOF 文件保存到磁盘。
既然 AOF 持久化是通过保存写命令到文件的，那随着时间的推移，这个 AOF 文件记录的内容就越来越多，文件体积也就越来越大，对其进行数据还原的时间也就越来越久。

在redis中AOF默认是关闭的，我们需要修改配置文件来开启AOF
appendonly yes //是否开启AOF持久化
appendfilename "appendonly.aof"//存储的文件的名称

AOF 重写

通过该功能来创建一个新的 AOF 文件来代替旧文件。并且两个文件所保存的数据库状态一样，但新文件不会包含任何冗余命令，所以新文件要比旧文件小得多。
因为重写涉及到大量 IO 操作，所以 Redis 是用子进程来实现这个功能的，否则将会阻塞主进程。该子进程拥有父进程的数据副本，可以避免在使用锁的情况下，保证数据的安全性。
为了解决数据库状态和重写后的 AOF 文件，所保存的数据库状态不一致的问题。
Redis 设置了一个 AOF 重写缓冲区。在子进程执行 AOF 重写期间，主进程需要执行以下三个步骤：

1. 执行客户端的请求命令
2. 将执行后的写命令追加到 AOF 缓冲区
3. 将执行后的写命令追加到 AOF 重写缓冲区

当子进程结束重写后，会向主进程发送一个信号，主进程接收到之后会调用信号处理函数执行以下步骤：

1. 将 AOF 重写缓冲区内容写入新的 AOF 文件中。此时新文件所保存的数据库状态就和当前数据库状态一致了
2. 对新文件进行改名，原子地覆盖现有 AOF 文件，完成新旧文件的替换。

当函数执行完成后，主进程就继续处理客户端命令。
因此，在整个 AOF 重写过程中，只有在执行信号处理函数时才会阻塞主进程，其他时候都不会阻塞。

简单总结一下

• RDB 持久化是 Redis 默认持久化方式，通过保存数据库键值对来记录状态来持久化，由 SAVE 和 BGSAVE 命令来创建 RDB 文件。前者阻塞 Redis 主进程，后者不会。
• RDB 可以在配置文件设置每隔多久时间来执行 BGSAVE 命令
• AOF 通过追加写命令来保存当前数据库状态。其持久化功能的实现可以分为 3 个步骤：命令追加（到 AOF 缓冲区）、文件写入（缓冲区内容写到 AOF 文件）、文件同步（AOF 文件保存磁盘）
• 为了解决 AOF 文件越来越大的问题，Redis 提供了 AOF 重写功能，并且不会阻塞主进程。
• 为了解决 AOF 重写过程中，新 AOF 文件所保存的数据库状态和当前数据库状态可能不一致的问题，Redis 引入了 AOF 重写缓冲区，用于保存子进程在重写 AOF 文件期间产生的新的写命令。

持久化官方建议

如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用 RDB。