redis 是个内存数据库，持久化就是把内存中的数据写入磁盘之中

redis 的持久化有 RDB 和 AOF

持久化

rdb&&aof

RDB

RDB(Redis DataBase)

RDB 就是在指定的时间间隔，执行数据集的时间点快照。实现类似照片记录效果的方式，把某一时刻的数据和状态文件写到磁盘上。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件被称为 RDB 文件（dump.rdb）。

Redis 的数据都在内存中，保存备份时它执行的是全量快照。恢复时再将硬盘快照文件直接读回到内存里。

配置文件

1
2

save 3600 1 300 100 60 10000
dbfilename dump.rdb

save 3600 1 300 100 60 10000 的含义是：

  1. save 3600 1：如果在 3600 秒（1 小时）内至少有 1 次写操作，Redis 将保存数据快照。
  2. save 300 100：如果在 300 秒（5 分钟）内至少有 100 次写操作，Redis 将保存数据快照。
  3. save 60 10000：如果在 60 秒（1 分钟）内至少有 10000 次写操作，Redis 将保存数据快照。

自动触发

自动触发的演示：

  1. 我们先将触发条件修改

    1

    save 5 2

    如果在 5 秒内有两次写操作，就会触发 RDB

  2. 修改后重启 redis-server

    image-20240604200238004

  3. 触发备份

    image-20240604200921091

    当我在 5 秒内写了两次，就触发了 RDB

  4. 如何恢复数据

    将备份文件dump.rdb移动到redis 安装目录，重启服务即可。

    备注：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了。

手动触发

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave

  • save

    在主程序中执⾏会阻塞当前redis服务器，直到持久化工作完成

    执行save命令期间，Redis不能处理其他命令，线上禁止使用

    save

    save2

  • bgsave

    Redis会在后台异步进行快照操作，不阻塞

    快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程

    Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。

    什么是 fork ？

    在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀。

    bgsave

LASTSAVE

可以通过lastsave命令获取最后一次成功执行快照的时间

lastsave

优势

  1. 适合大规模的数据恢复
  2. 按照业务定时备份
  3. 对数据完整性和一致性要求不高
  4. RDB 文件在内存中的加载速度要比 AOF 快得多

劣势

  1. 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
  2. 内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能
  3. RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑

如何检查修复 dump.rdb 文件

image-20240604204937122

哪些情况会触发 RDB 快照

  1. 配置文件中默认的快照配置
  2. 手动save/bgsave命令
  3. 执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
  4. 执行shutdown且没有设置开启AOF持久化
  5. 主从复制时，主节点自动触发

如何禁用快照

image-20240604205248246

RDB 优化配置

配置文件SNAPSHOTTING模块

  • save

  • dbfilename

  • dir

  • stop-writes-on-bgsave-error

    image-20240604205352453

    默认yes

    如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，

    也能确保redis继续接受新的写请求

  • rdbcompression

    默认yes

    对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。

    如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

  • rdbchecksum

    默认yes

    在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

  • rdb-del-sync-files

    rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。

image-20240604205520372

AOF

AOF（Append Only File）

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，

只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

默认情况下，redis是没有开启AOF(append only file)的。

开启AOF功能需要设置配置：appendonly yes

AOF保存的是 appendonly.aof 文件（在 redis7 中是三个文件）

image-20240605161445841

AOF 持久化过程

aof 过程

  1. Client作为命令的来源，会有多个源头以及源源不断的请求命令。
  2. 在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
  3. AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
  4. 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
  5. 当 Redis Server 服务器重启的时候会从AOF文件载入数据。

AOF缓冲区三种写回策略

aof写回策略

  • always

    同步写回，每个写命令执行完立刻同步地将日志写回磁盘

  • everysec

    每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘

  • no

    操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

写回策略

优势

aof优势

更好的保护数据不丢失 、性能高、可做紧急恢复

劣势

aof 劣势

  • 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
  • aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

AOF 重写机制

AOF 重写机制是对 AOF 文件的压缩，只保留可以恢复数据的最小指令集。

触发机制

1
2

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

注意 ，同时满足，且的关系才会触发

1 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍

2 重写时满足的文件大小

自动触发：

满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时

手动触发：

客户端向服务器发送bgrewriteaof命令

image-20240605161816050

重写原理

1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中

4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中

5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

AOF优化配置项

image-20240605163549244

image-20240605163559040

RDB-AOF 混合持久化

怎么选择？

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.

同时开启

如果同时开启 rdb 和 aof，重启时只会加载 aof 文件，不会加载 rdb 文件。

image-20240605163814675

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。

推荐方式

🏮 RDB + AOF 混合方式

结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

  1. 开启混合方式设置

    设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用

  2. RDB+AOF的混合方式———> 结论：RDB镜像做全量持久化，AOF做增量持久化

    先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。

    简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。—-》AOF包括了RDB头部+AOF混写

    image-20240605164403258