Redis持久化

发表于 分类于

简述

redis有两种持久化方式：RDB（Redis DataBase）持久化和 AOF（Append Only File）。

RDB：通过创建数据的快照，在指定时间间隔内将redis某个时刻的数据状态保存到磁盘RDB文件中。

AOF：通过记录每个操作命令并将其追加到AOF文件中，恢复时通过执行这些命令来重建数据。

image-20240331163759309

RDB持久化

RBD以快照的方式保存全量的数据，可通过save和bgsave两个命令来触发持久化。

1、save命令：会同步地将 Redis 的所有数据保存到磁盘上的一个 RDB 文件中。这个操作会阻塞所有客户端请求直到 RDB 文件被完全写入磁盘。

2、bgsave命令：会在后台异步地创建 Redis 的数据快照，并将快照保存到磁盘上的 RDB 文件中。这个命令会立即返回，Redis 服务器可以继续处理客户端请求。

image-20240331165755573

AOF持久化

AOF以追加的方式保存增量的数据，AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。

AOF 的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）。

image-20240331171433901

流程如下：

1）当 AOF 持久化功能被启用时，Redis 服务器会将接收到的所有写命令（比如 SET, LPUSH, SADD 等修改数据的命令）追加到 AOF 缓冲区（buffer）的末尾。

2）为了将缓冲区中的命令持久化到磁盘中的 AOF 文件，Redis 提供了几种不同的同步策略：

  • always：每次写命令都会同步到 AOF 文件，这提供了最高的数据安全性，但可能因为磁盘 I/O 的延迟而影响性能。
  • everysec（默认）：每秒同步一次，这是一种折衷方案，提供了较好的性能和数据安全性。
  • no：不主动进行同步，交由操作系统决定何时将缓冲区数据写入磁盘，这种方式性能最好，但在系统崩溃时可能会丢失最近一秒的数据。

3）随着操作的不断执行，AOF 文件会不断增长，为了减小 AOF 文件大小，Redis 可以重写 AOF 文件：

  • 重写过程不会解析原始的 AOF 文件，而是将当前内存中的数据库状态转换为一系列写命令，然后保存到一个新的 AOF 文件中。
  • AOF 重写操作由 BGREWRITEAOF 命令触发，它会创建一个子进程来执行重写操作，因此不会阻塞主进程。
  • 重写过程中，新的写命令会继续追加到旧的 AOF 文件中，同时也会被记录到一个缓冲区中。一旦重写完成，Redis 会将这个缓冲区中的命令追加到新的 AOF 文件中，然后切换到新的 AOF 文件上，以确保数据的完整性。

4）当 Redis 服务器启动时，如果配置为使用 AOF 持久化方式，它会读取 AOF 文件中的所有命令并重新执行它们，以恢复数据库的状态。

两者优缺点

RDB-优点

  1. 集中备份，则文件紧凑， dump.rdb，非常适合备份、全量复制的场景。
  2. 容灾性好，RDB 文件可以直接拷贝使用，用于容灾恢复。
  3. 恢复速度快，RDB文件集中紧凑， 则速度快

RDB-缺点

  1. 实时性低，RDB 是间隔一段时间进行持久化，无法实时持久化。如果在这时间段发生故障，则数据会丢失。
  2. 存在兼容问题，Redis 演进过程存在多个格式的 RDB 版本，存在老版本 Redis 无法兼容新版本 RDB 的问题。

AOF-优点

  1. 实时性好，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 aof 文件中一次。
  2. 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。

AOF-缺点

  1. AOF 文件比 RDB 文件大，且 恢复速度慢。
  2. 数据集大 的时候，比 RDB 启动效率低。

两者如何选择

1、只选RDB，可能会有数分钟的数据丢失。

2、只选AOF，不利于备份，恢复速度也慢。

3、两者配合，两种持久化方式都选，这种情况下Redis重启时会优先载入AOF文件来恢复数据，因为AOF文件的数据集比RDB全。

4、都不选，不持久化。

故障数据恢复

Redis 启动时加载数据的流程：

1、判断AOF开启且AOF文件是否存在，存在则优先加载

2、如果AOF关闭或者不存在，则加载RDB文件

3、文件加载成功后则Redis启动成功

4、加载失败，则启动失败

image-20240331174017060