人的知识就好比一个圆圈，圆圈里面是已知的，圆圈外面是未知的。你知道得越多，圆圈也就越大，你不知道的也就越多。

0%

Redis 持久化机制

发表于 更新于 分类于

Redis 的数据默认全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制。

Redis 的持久化机制有两种：

  • RDB 快照
  • AOF 日志

RDB 快照是一次全量备份，AOF 日志是连续的增量备份；快照是内存数据的二进制序列化形式，在存储上非常紧凑，而 AOF 日志记录的是内存数据修改的指令记录文本。

对比

RDB 快照

优点：

  • RDB 快照是紧凑的二进制文件，比较适合做冷备，全量复制的场景。
  • 相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 Redis 进程，更加快速。

缺点：

  • 如果想要在 Redis 实例发生故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好。
  • RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。
  • RDB 无法实现实时或者秒级持久化。

AOF 日志

优点：

  • AOF 日志可以更好的保护数据不丢失。
  • AOF 日志文件以 append-only 模式写入，写入性能比较高。
  • AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
  • 适合做灾难性的误删除紧急恢复。

缺点：

  • 对于同一份数据来说，AOF 日志文件通常比 RDB 快照文件更大，恢复速度慢。
  • AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 fsync 一次日志文件。（当然，每秒一次 fsync，性能也还是很高的。）
  • 以前 AOF 发生过bug，就是通过 AOF 记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

配置

RDB 快照

默认情况下，Redis 是 RDB 快照的持久化方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是 dump.rdb。

redis.conf 默认配置：

1
2
3
save 900 1
save 300 10
save 60 10000

配置含义：

  • 900 秒内，如果超过 1 个 key 被修改，则发起快照保存。
  • 300 秒内，如果超过 10 个 key 被修改，则发起快照保存。
  • 60 秒内，如果 1 万个 key 被修改，则发起快照保存。

AOF 日志

如果要开启 AOF 日志持久化方式，需要将 appendonly 设置为 yes。（开启后在服务端会发现多了一个 appendonly.aof 文件。）

1
2
3
4
appendonly yes

# 默认每秒持久化一次
# appendfsync everysec

默认是每秒持久化一次。通过指定不同的 appendfsync 值，可以实现不同的持久化策略。

  • no：不主动进行同步操作，默认 30s 一次
  • everysec：每秒持久化一次(默认配置)
  • always：每次操作都会立即写入 aof 文件中

混合持久化

1
aof-use-rdb-preamble yes

原理

RDB 快照

Redis 使用操作系统的多进程 COW（Copy On Write）机制来实现快照持久化。

Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。

子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段。我们可以将父子进程想象成一个连体婴儿，共享身体。这是 Linux 操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来。在进程分离的一瞬间，内存的增长几乎没有明显变化。

子进程做数据持久化，它不会修改现有的的内容数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对内存数据结构进行不间断的修改。

这个时候就会使用操作系统的 COW 机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。

随着父进程修改操作的持续进行，越来越多的共享页面被分离出来，内存就会持续增长。但是也不会超过原有数据内存的 2 倍大小。另外一个 Redis 实例里冷数据占的比例往往是比较高的，所以很少会出现所有的页面都会被分离，被分离的往往只有其中一部分页面。每个页面的大小只有 4k，一个 Redis 实例里一般都会由成千上万的页面。

子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化叫做“快照”的原因。

AOF 日志

AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的指令记录。

假设 AOF 日志记录了自 Redis 实例创建以来所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例顺序执行所有的指令，也就是“重放”，来恢复 Redis 当前实例的内存数据结构的状态。

Redis 会在收到客户端修改指令后，进行参数校验进行逻辑处理后，如果没问题，就立即将该指令文本存储到 AOF 日志中，也就是先执行指令才将日志存盘。

Redis 在长期运行的过程中，AOF 的日志会越变越长。如果实例宕机重启，重放整个 AOF 日志会非常耗时，导致长时间 Redis 无法对外提供服务。所以需要对 AOF 日志瘦身。

AOF 重写

Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。

fsync

AOF 日志是以文件的形式存在的，当程序对 AOF 日志文件进行写操作时，实际上是将内容写到了内核为文件描述符分配的一个内存缓存中，然后内核会异步将脏数据刷回到磁盘的。

这就意味着如果机器突然宕机，AOF 日志内容可能还没有来得及完全刷到磁盘中，这个时候就会出现日志丢失。那该怎么办？

Linux 的 glibc 提供了 fsync(int fd) 函数可以将指定文件的内容强制从内核缓存刷到磁盘。只要 Redis 进程实时调用 fsync 函数就可以保证 aof 日志不丢失。但是 fsync 是一个磁盘 IO 操作，它很慢！如果 Redis 执行一条指令就要 fsync 一次，那么 Redis 高性能的地位就不保了。

所以在生产环境的服务器中，Redis 通常是每隔 1s 左右执行一次 fsync 操作，周期 1s 是可以配置的。这是在数据安全性和性能之间做了一个折中，在保持高性能的同时，尽可能使得数据少丢失。

Redis 同样也提供了另外两种策略，一个是从不 fsync–让操作系统来决定何时同步磁盘，很不安全，另一个是来一个指令就 fsync 一次–非常慢。这两种策略在生产环境基本不会使用。

混合持久化

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项：混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。

于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

当然混合持久化也是有缺点的，就是 aof 日志里面的 rdb 部分就是压缩格式不再是 aof 格式，可读性差。

运维

通常 Redis 的主节点不会进行持久化操作，持久化操作主要在从节点进行。从节点是备份节点，没有来自客户端请求的压力，它的操作系统资源往往比较充沛。

但是如果出现网络分区，从节点长期连不上主节点，就会出现数据不一致的问题，特别是在网络分区初出现的情况下又不小心主节点宕机了，那么数据就会丢失，所以在生产环境要做好实时监控工作，保证网络畅通或者能快速修复。另外还应该再增加一个从节点以降低网络分无的概率，只要有一个从节点数据同步正常，数据也就不会轻易丢失。

小礼物走一走，来 Github 关注我