万隆的笔记
2022-03-30
目录

Redis持久化

# Redis持久化

只要是数据库，就离不开持久化的话题。

Redis是内存数据库，宕机后数据会消失。如果重启后需要恢复数据，那么就要提供持久化机制。

Redis有两种持久化方式：RDB和AOF。进入命令行，可以通过info命令可以查看关于Redis持久化的信息。

注意，Redis的持久化是不保证数据完整性的。如果Redis用作DB时，要保持数据的完整性，必须提供一个完整的数据源（文件、mysql），在系统启动时，从这个完整的数据源中将数据加载到Redis中。

# RDB

RDB（Redis DataBase），是Redis默认的持久化存储方式。通过快照（ snapshotting ，某个时刻的数据信息）的方式完成持久化。

# 参数配置

RDB可以在redis.conf中配置多个save规则定期执行，默认配置如下（建议采默认的）：

# save ""        # 表示不使用RDB存储 不能主从（没人会配置这个吧） 
save 900 1       # 表示15分钟（900秒钟）内至少1个键被更改则进行快照。 
save 300 10      # 表示5分钟（300秒）内至少10个键被更改则进行快照。 
save 60 10000    # 表示1分钟内至少10000个键被更改则进行快照。

# 触发快照的方式

  1. 自定义配置的快照规则（上面的配置）

  2. 执行save或者bgsave命令

    127.0.0.1:6379> bgsave
Background saving started

  3. 执行flushall命令

  4. 第一次执行主从复制操作

# RDB执行原理

RDB的执行原理的核心是fork主进程，子进程去进行数据拷贝持久化。下面以bgsave的执行流程为例：

rdb1

  1. Redis父进程首先判断：当前是否在执行save、bgsave、bgrewriteaof（aof文件重写命令）的子进程，如果在执行则bgsave命令直接返回。
  2. 父进程执行fork（调用OS函数复制主进程）操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令。
  3. 当父进程fork的过程完成，bgsave命令返回“Background saving started”信息并不再阻塞父进程，并可以响应其他命令，继续工作。
  4. 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换（RDB始终完整）。
  5. 子进程发送信号给父进程表示完成，父进程更新统计信息。

# RDB文件结构

.rdb文件是一个二进制文本文件，如果直接用编辑器打开通常是“乱码”，在这里我们了解一下它的文件结构即可：

rdb2

  • “REDIS”：与大多数文件系统一样，都会有个“魔数”，即文件标识，rdb的标识就是头部5字节固定为“REDIS”。

  • RDB_VERSION：4字节，“RDB”版本号，假如当前为9，填充后为0009

  • AUX_FIFLD_KEY_VALUE_PAIRS：辅助字段，以key-value的形式保存：

    字段名称 值 字段名称 值
    redis-ver 5.0.5（reids版本） aof-preamble 是否开启aof
    redis-bits 64/32 repl-stream-db 主从复制
    ctime 当前时间戳 repl-id 主从复制

  • DB_NUM：存储数据库号码

  • DB_DICT_SIZE：字典大小

  • EXPIRE_DICT_SIZE：过期key

  • KEY_VALUE_PAIRS：我们存储的主要数据，以key-value的形式存储

  • EOF：结束标志

  • CHECK_SUM：校验和，就是看文件是否损坏，或者是否被修改。

# RDB优缺点

优点：

  • RDB是二进制压缩文件，占用空间小，便于传输，方便主从同步。
  • 主进程fork子进程，可以最大化Redis性能，但是主进程不能太大，因为复制过程中主进程阻塞。

缺点：

  • 不保证数据完整性，会丢失最后一次快照以后更改的所有数据。

# AOF

AOF（Append Only File）是Redis的另一种持久化方式。Redis默认情况下是不开启的。

AOF持久化的机制是将所有对Redis数据库进行过写入的命令包含参数（RESP）记录到 AOF 文件， 以此达到记录数据库状态的目的，这样当Redis重启后只要按顺序回放这些命令就会恢复到原始状态了。

简单来说，AOF会记录过程，而RDB只管结果。

# 参数配置

在 redis.conf 配置文件中，进行以下配置就可以开启AOF持久：

# 开启 appendonly 参数
appendonly yes 
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置
dir ./
# 默认文件名appendonly.aof，可以自己修改
appendfilename appendonly.aof

# AOF原理

AOF文件中存储的是redis的命令，同步命令到 AOF 文件的整个过程可以分为三个阶段：

  • 命令传播：Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。
  • 缓存追加：AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议（RESP）的格式，然后将协议内容追加到服务器的 AOF 缓存中。(传播过来的命令转化为RESP并缓存起来)
  • 文件写入和保存：AOF 缓存中的内容被写入（追加）到 AOF 文件末尾，如果设定的 AOF 保存条件被满足的话，fsync 函数或者 fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中。

# 命令传播

当一个 Redis 客户端需要执行命令时， 它通过网络连接， 将协议文本发送给 Redis 服务器。服务器在接到客户端的请求之后， 它会根据协议文本的内容， 选择适当的命令函数， 并将各个参数从字符串文本转换为 Redis 字符串对象（ StringObject ）。每当命令函数成功执行之后， 命令参数都会被传播到AOF 程序。

# 缓存追加

当命令被传播到 AOF 程序之后， 程序会根据命令以及命令的参数， 将命令从字符串对象转换回原来的协议文本。协议文本生成之后， 它会被追加到 redis.h/redisServer 结构的 aof_buf （缓存）末尾。redisServer 结构维持着 Redis 服务器的状态， aof_buf域则保存着所有等待写入到 AOF 文件的协议文本（RESP）。

# 文件写入和保存

每当服务器常规任务函数被执行、 或者事件处理器被执行时， aof.c/flushAppendOnlyFile 函数都会被调用， 这个函数执行以下两个工作（写入和保存）：

  • WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。
  • SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。下面会介绍save的保存模式。

# AOF保存模式

Redis 目前支持三种 AOF 保存模式，它们分别是：

  • AOF_FSYNC_NO ：不保存。这里其实是被动保存。在这种模式下， 每次调用 flushAppendOnlyFile 函数， WRITE 都会被执行， 但 SAVE 会被略过。SAVE 只会在以下任意一种情况中被执行：

    • Redis 被关闭
    • AOF 功能被关闭
    • 系统的写缓存被刷新（可能是缓存已经被写满，或者定期保存操作被执行）

    但是，这三种情况下的 SAVE 操作都会引起 Redis 主进程阻塞。

  • AOF_FSYNC_EVERYSEC（默认） ：每一秒钟保存一次。在这种模式中， SAVE 原则上每隔一秒钟就会执行一次， 因为 SAVE 操作是由后台子线程（fork）调用的， 所以它不会引起服务器主进程阻塞。

  • AOF_FSYNC_ALWAYS（不推荐） ：每执行一个命令保存一次。在这种模式下，每次执行完一个命令之后， WRITE 和 SAVE 都会被执行。另外，因为 SAVE 是由 Redis 主进程执行的，所以在 SAVE 执行期间，主进程会被阻塞，不能接受命令 请求。

对于三种 AOF 保存模式， 它们对服务器主进程的阻塞情况如下：

模式 WRITE是否阻塞 SAVE是否阻塞 停机时丢失的数据量
AOF_FSYNC_NO 阻塞 阻塞 OS最后一次对AOF文件出发SAVE操作之后的数据
AOF_FSYNC_EVERYSEC 阻塞 不阻塞（fork） 一般情况丢失不会超过两秒的数据
AOF_FSYNC_ALWAYS 阻塞 阻塞 最多丢失一个命令的数据

# AOF重写原理

由于AOF记录的是一个个的执行命令，在AOF记录数据的变化过程，文件会越来越大，这个时候需要重写“瘦身”。

Redis可以在 AOF体积变得过大时，自动地在后台（Fork子进程）对 AOF进行重写。重写后的新 AOF文件包含了恢复当前数据集所需的最小命令集合。 所谓的“重写”其实是一个有歧义的词语， 实际上，AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取， 它针对的是数据库中键的当前值。举例如下：

# 重写前
set k1 11
set k1 22
set k1 33
# 重写后
set s1 33

# 重写前
lpush list1 1 2 3
lpush list1 4 5 6 
# 重写后
lpush list1 1 2 3 4 5 6

Redis 不希望 AOF 重写造成服务器无法处理请求， 所以 Redis 决定将 AOF 重写程序放到（后台）子进程里执行， 这样处理的最大好处是：

  • 子进程进行 AOF 重写期间，主进程可以继续处理命令请求。
  • 子进程带有主进程的数据副本，使用子进程而不是线程，可以在避免锁的情况下，保证数据的安全性。

不过， 使用子进程也有一个问题需要解决： 因为子进程在进行 AOF 重写期间， 主进程还需要继续处理命令， 而新的命令可能对现有的数据进行修改， 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。

为了解决这个问题， Redis 增加了一个 AOF 重写缓存， 这个缓存在 fork 出子进程之后开始启用，Redis 主进程在接到新的写命令之后， 除了会将这个写命令的协议内容追加到现有的 AOF 文件之外，还会追加到这个缓存中。

aof2

重写的过程安全吗？

整个重写操作是绝对安全的！Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

当子进程在执行 AOF 重写时， 主进程需要执行以下三个工作：

  • 处理命令请求。
  • 将写命令追加到现有的 AOF 文件中。
  • 将写命令追加到 AOF 重写缓存中。

这样一来可以保证现有的 AOF 功能会继续执行，即使在 AOF 重写期间发生停机，也不会有任何数据丢失。所有对数据库进行修改的命令都会被记录到 AOF 重写缓存中。当子进程完成 AOF 重写之后， 它会向父进程发送一个完成信号， 父进程在接到完成信号之后， 会调用一个信号处理函数， 并完成以下工作：

  • 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中（执行完毕之后， 现有 AOF 文件、新 AOF 文件和数据库三者的状态就完全一致了）。
  • 对新的 AOF 文件进行改名，覆盖原有的 AOF 文件（执行完毕之后， 程序就完成了新旧两个 AOF 文件的交替）。

这个信号处理函数执行完毕之后， 主进程就可以继续像往常一样接受命令请求了。 在整个 AOF 后台重写过程中， 只有最后的写入缓存和改名操作会造成主进程阻塞， 在其他时候， AOF 后台重写都不会对主进程造成阻塞， 这将 AOF 重写对性能造成的影响降到了最低。

以上就是 AOF 后台重写， 即 BGREWRITEAOF 命令(AOF重写)的工作原理。简单一句话总结过程就是AOF重写就是：

Redis数据库的数据+AOF重写过程中的命令 = 新的AOF文件 ---替换---》老的AOF。

# AOF重写触发方式

  1. 在redis.conf中配置触发

    # 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准 
auto-aof-rewrite-percentage 100 
# 限制允许重写最小aof文件的大小，也就是文件大小小于64mb的时候，不需要进行优化 
auto-aof-rewrite-min-size 64mb

  2. grewriteaof命令

    127.0.0.1:6379> bgrewriteaof 
Background append only file rewriting started

# AOF文件的载入与数据还原

因为AOF文件里面包含了重建数据库状态所需的所有写命令，所以服务器只要读入并重新执行一遍AOF文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。

Redis读取AOF文件并还原数据库状态的详细步骤如下：

  1. 创建一个不带网络连接的伪客户端（fake client）：因为Redis的命令只能在客户端上下文中执行，而载入AOF文件时所使用的命令直接来源于AOF文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行AOF文件保存的写命令，伪客户端执行命令 的效果和带网络连接的客户端执行命令的效果完全一样
  2. 从AOF文件中分析并读取出一条写命令
  3. 使用伪客户端执行被读出的写命令
  4. 一直重复执行步骤2和步骤3，直到AOF文件中的所有写命令都被处理完毕为止

当完成以上步骤之后，AOF文件所保存的数据库状态就会被完整地还原出来，整个过程如下图所示：

aof2

# AOF优缺点

优点：

  • 数据安全性相对较高，根据使用的fsync策略，每秒执行一次fsync，在这种配置下，redis仍然可以保持良好的性能，并且就算发生故障停机，最多指挥丢失一秒钟的数据
  • Redis可以在aof文件体积变得过大时，自动的在后台对aof进行重写，重写后的新aof文件包含了恢复当前数据集所需要的最小命令集合。
  • AOF日志文件格式清晰、易于理解。可以通过该文件完成数据的重建。

缺点

  • 即使有些操作是重复的也会全部记录，通常来说aof文件比rdb大。
  • AOF在恢复大数据集时的速度比RDB的恢复速度要慢
  • 根据fsync策略不同，AOF速度可能会慢于RDB

# 混合持久化

RDB和AOF各有优缺点，Redis 4.0 开始支持 rdb 和 aof 的混合持久化。如果把混合持久化打开，aof rewrite 的时候就直接把 rdb 的内容写到 aof文件开头：RDB的头 + AOF 的身体 = appendonly.aof。

开启混合持久化配置如下：

aof-use-rdb-preamble yes

# RDB与AOF该如何选择

首先对比一下RDB与AOF：

  • 存储的方式：RDB存的是某个时刻的数据快照，采用二进制压缩存储，AOF存操作命令，采用文本存储(混合)
  • 数据完整性：RDB在配置触发状态会丢失最后一次快照以后更改的所有数据，如果AOF设置保存模式为每秒保存一次，则最多丢2秒的数据
  • 对过期Key的处理：当Redis以主服务器模式运行，RDB不会保存过期键值对数据，Redis以从服务器模式运行，RDB会保存过期键值对，当主服务器向从服务器同步时，再清空过期键值对。AOF写入文件时，对过期的key会追加一条del命令，当执行AOF重写时，会忽略过期key和del命令。
  • 综合性能：RDB性能高、AOF性能较低

可以综合上述的情况以及自己Redis的用途，去决定使用哪种持久化机制，通常有以下经验：

  • Redis作为DB使用，那么可以 RDB+AOF，这样数据不容易丢失。
  • Redis用作缓存服务器或可以承受数分钟数据的丢失，开启RDB够了，因为性能高。

总体来说，不太推荐开启AOF，因为性能差。此外，如果需要还原数据，在有AOF文件的情况下，反而建议以AOF文件为准，因为它最多丢失一两秒的数据。

上次更新: 5/30/2023, 11:42:20 PM
Redis发布与订阅

Redis发布与订阅→

最近更新
01
2025
01-15
02
Elasticsearch面试题
07-17
03
Elasticsearch进阶
07-16
更多文章>
Theme by Vdoing