redis----RDB & AOF持久化 &混合持久化

m0_46598535

已于 2022-07-14 23:10:27 修改

阅读量400

点赞数

分类专栏： redis 文章标签： redis 缓存数据库

于 2022-06-16 12:40:22 首次发布

本文链接：https://blog.csdn.net/m0_46598535/article/details/125309584

版权

redis 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

lua

lua脚本的几个命令，在redis中会被当作一条命令执行

Redis 中的持久化 RDB持久化
 Redis写时复制

RDB持久化

bgsave
Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。Redis 只会在 fork 期间发生阻塞，但是一般时间都很短。但是如果 Redis 数据量特别大，fork 时间就会变长，而且占用内存会加倍，这一点需要特别注意。
bgsave-写时复制技术
子进程刚刚产生时，和父进程共享内存里面的代码段和数据段，也就是说，父子进程的虚拟空间不同，但其对应的物理空间（内存区）是同一个。
为什么是fork出进程而不是线程
答案：主要是出于Redis性能的考虑，(1)Redis RDB持久化机制会阻塞主进程，这样主进程就无法响应客户端请求。(2)我们知道Redis对客户端响应请求的工作模型是单进程和单线程的，如果在主进程内启动一个线程，这样会造成对数据的竞争条件，为了避免使用锁降低性能。基于以上两点这就是为什么Redis通过启动一个进程来执行RDB了。

RDB缺点：
RDB快照并不是很可靠。如果你的电脑突然宕机了，或者电源断了，又或者不小心杀掉了进程，那么最新的数据就会丢失。除了 RDB 持久化功能之外，Redis 还提供了 AOF(Append Only File) 持久化功能。

AOF

每当 Redis 接受到会修改数据集的命令时，就会把命令追加到 AOF 文件里，当你重启 Redis 时，AOF 文件里的命令会被重新执行一次，重建数据。
因为 AOF 文件里面包含了重建数据库状态所需的所有写命令，所以服务器只要读入并重新执行一遍 AOF 文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。

AOF 文件中的所有命令都是以 Redis 的命令请求协议格式保存的。
服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。
在这里插入图片描述

aof的介绍
 aof的重写原理
 AOF的阻塞点
 Redis中存在的两大阻塞：fork阻塞和AOF追加阻塞

AOF重写：

Redis 的 AOF 重写是fork子进程里执行，这样做可以同时达到两个目的：

1.子进程进行 AOF 重写期间，服务器（父进程）可以继续处理命令请求。

2.子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

但是，使用子进程也有一个问题需要解决，因为子进程在进行 AOF 重写期间，服务器进程还需要继续处理命令请求，而新的命令可能会对现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写后的 AOF 文件所保存的数据库状态不一致。

为了解决数据不一致问题，Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当 Redis 服务器执行完一个写命令之后，它会同时将这个写命令发送给 AOF 缓冲区和 AOF 重写缓冲区，如图 1-4-2 所示。

在这里插入图片描述

这样一来可以保证：

AOF 缓冲区的内容会定期被写入和同步到 AOF 文件，对现有 AOF 文件的处理工作会如常进行。

从创建子进程开始，服务器执行的所有写命令都会被记录到 AOF 重写缓冲区里面。

当子进程完成 AOF 重写工作之后，它会向父进程发送一个信号，父进程在接到该信号后，会调用一个信号处理函数，并执行一下工作：

将 AOF 重写缓冲区中的所有内容写入到新 AOF 文件中，这是新的 AOF 文件所保存的数据库状态将和服务器当前的数据库状态一致。

对新的 AOF 文件进行改名，原子地（atomic）覆盖现有的 AOF 文件，完成新旧两个 AOF 文件的替换。

这个信号处理函数执行完毕之后，父进程就可以继续像往常一样接受命令请求了。

在整个 AOF 后台重写过程中，只有信号处理函数执行时会对服务器进程（父进程）造成阻塞，在其他时候，AOF 后台重写不会阻塞父进程，这将 AOF 重写对服务器性能造成的影响降到了最低。

RDB和AOF各自的缺点：

RDB是每隔一段时间持久化一次, 故障时就会丢失宕机时刻与上一次持久化之间的数据，无法保证数据完整性。
AOF存储的是指令序列, 恢复重放时要花费很长时间并且文件更大。

Redis 4.0 提供了更好的混合持久化选项：

fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据。