深入解析Redis持久化机制

发表时间: 2024-05-10 20:46

快速了解：
1、RDB持久化方式有哪些？
2、RDB持久化方式的原理
3、RDB各种持久化方式的优缺点
4、了解RDB的AOF文件重写机制

持久化方式

有三种持久化方式：

一种叫做RDB(内处快照)，它按照配置的策略来将所有的数据写到磁盘里面。对应rdb文件

一种叫AOF(只追加文件)，它将执行的写命令复制到磁盘里面。对应aof文件

另外一种衍生出来的：

混合持久化

RDB和AOF都各有优缺点，所以Redis采用混合持久化的方式来保存数据，即保证一定的加载速度，又尽可能的少丢失数据。

持久化配置

持久化RDB原理

其实就是依赖两个指令来进行保存：save、bgsave

在Redis中RDB持久化的触发分为两种：自己手动触发与 Redis定时触发。

针对RDB方式的持久化，手动触发可以使用：

save：会阻塞当前Redis服务器，也就是主进程，直到持久化完成，线上应该禁止使用。
bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。

bgsave 就有点异步处理的意思。

而自动触发的场景主要是有以下几点(bgsave的场景)：

根据我们的 save m n 配置规则自动触发；
从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave；
执行 debug reload 时；
执行 shutdown时，如果没有开启aof，也会触发。

save 基本不会被使用到，重点看看 bgsave 这个命令是如何完成RDB的持久化的。

Redis客户端执行bgsave命令或自动触发bgsave命令；
父进程先判断：当前是否在执行save，或bgsave/bgrewriteaof（aof文件重写命令）的持久化子进程
如果存在：则父进程直接返回。如果不存在：父进程执行fork操作创建一个子进程，fork过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
fork完毕后返回 “ Background saving started” 信息并不再阻塞父进程，并可响应其他命令
子进程创建临时RDB文件，待数据写入完毕后，对原有文件进行原子替换；
同时子进程退出，并发送信号给父进程表示完成rdb持久化，父进程更新统计信息

持久化AOF原理

1、aof文件过大恢复时间过长怎么办
2、AOF持久化文件越来越大这么办
-->聊聊重写机制

大概过程是这样：

当Redis执行一个写操作（如set、del等），会将这个写操作的命令通过I/O的方式写入到AOF缓冲区。
根据配置文件中的AOF写入策略（always, everysec, no），将缓冲区的内容写入到AOF文件中。
Redis进程通过文件的方式，将AOF文件的内容同步到磁盘上，确保数据的持久化。

重写机制

为什么需要

AOF是Redis增量模式的持久化方式，随着redis的持续运行，会不断有新的数据写入AOF文件中，逐渐占用大量磁盘空间，还会降低Redis启动时候的加载效率。Redis为了解决这个问题，设计了AOF重写机制，也就是说把AOF文件里面相同的指令进行压缩，只保留最新的数据指令。

触发时机

AOF 重写机制可以由用户手动触发，也可以由系统自动触发。
用户手动触发 AOF 重写机制可以通过执行 BGREWRITEAOF 命令来实现。
系统自动触发 AOF 重写机制可以通过配置文件中的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 参数来控制。
auto-aof-rewrite-percentage 参数表示当当前 AOF 文件大小超过上次重写后 AOF 文件大小的百分比时，触发 AOF 重写机制，默认值为 100 。
auto-aof-rewrite-min-size 参数表示当当前 AOF 文件大小超过指定值时，才可能触发 AOF 重写机制，默认值为 64 MB 。

重写过程

AOF 重写机制是通过 fork 出一个子进程来完成的，子进程首先会扫描 Redis 的数据库，并将每个键值对转换为相应的写入命令，然后写入到一个临时文件中。
在子进程进行 AOF 重写的过程中，主进程还会继续接收和处理客户端的请求，如果有新的写操作发生，主进程会将这些写操作追加到一个缓冲区中，并通过管道通知子进程。
子进程在完成 AOF 重写后，会将缓冲区中的写操作也追加到临时文件中，然后向主进程发送信号，通知主进程可以切换到新的 AOF 文件了。
主进程在收到子进程的信号后，会将缓冲区中的写操作再次追加到临时文件中（以防止在此期间有新的写操作发生），然后用临时文件替换旧的 AOF 文件，并关闭旧的 AOF 文件。

混合持久化原理

混合持久化方式的执行流程和aof重写执行流程基本一致，只是在执行重写的那一步不是将aof文件中的命令进行压缩重写，而是将重写这一刻之前的内存做RDB快照，之后将aof_rewrite_buf中的命令追加存储起来，形成一个由rdb格式和aof格式混合组成的新文件。

具体实现

aof和rdb格式同时存在,本质上是aof文件。
数据被添加到aof缓冲区中,每隔1S同步到aof文件中。
当数据慢慢变多，此时触发重写机制，将当前的数据以rdb格式进行保存，并添加到aof文件的开头，后续的数据还是以aof机制的形式添加，直到下一次重写。
奔溃重启时，先加载rdb部分，再加载aof部分。

优点

先加载rdb,再加载aof，这样恢复速度不至于太慢。
缓冲区同步采用aof机制,同步频率高，丢失数据少。

AOF和RDB的优缺点

RDB的优缺点

优点

RDB最大限度地提高了Redis的性能，父进程不需要参与磁盘I/O
适合备份：RDB生成的文件紧凑,是一个压缩的二进制文件
适合恢复：在恢复大数据集时的速度比 AOF 的恢复速度要快

缺点

影响服务性能：每次快照是一次全量备份，如果数据量太大会导致I/O严重影响服务的性能
可能丢失数据：由于是间隔性备份，如果redis的意外宕机等，快照有可能会丢失部分数据

AOF的优缺点

优点：

数据有保障。数据更加安全，不容易丢失
当Redis AOF文件太大时，Redis能够在后台自动重写AOF
AOF以易于理解和解析的格式，一个接一个地包含所有操作的日志

缺点：

体积大。AOF文件通常比同一数据集的等效RDB文件大
恢复慢。根据确切的fsync策略，恢复的时候AOF可能比RDB慢

如何选择使用哪种持久化方式?

看业务需求：

如果想达到足以媲美 PostgreSQL 的数据安全性，你应该同时使用两种持久化功能.

如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化，但我们并不推荐这种方式: 因为定时生成 RDB 快照(snapshot) 非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，除此之外，使用 RDB 还可以避免之前提到的 AOF 程序的 bug.

推荐是两者均开启
如果对数据不敏感，可以选单独用RDB
不建议单独用AOF，因为可能会出现Bug
如果只是做纯内存缓存，可以都不用