Redis持久化

最新推荐文章于 2025-03-02 19:01:04 发布

FYHannnnnn

最新推荐文章于 2025-03-02 19:01:04 发布

阅读量112

点赞数

分类专栏： Redis 文章标签：数据库 database Redis

本文链接：https://blog.youkuaiyun.com/qq_42773863/article/details/121409351

版权

Redis 专栏收录该内容

17 篇文章

订阅专栏

为什么要持久化?

Redis是内存数据库，宕机后数据会消失。 Redis重启后快速恢复数据，要提供持久化机制。

Redis持久化方式

Redis支持RDB与AOF两种持久化方式。

关于持久化的配置信息查看

可通过info命令查看

一，RDB

RDB（Redis DataBase），是redis默认的存储方式，RDB方式是通过快照（ snapshotting ）完成的。这一刻的数据不关注过程。

触发RDB的方式：

符合自定义配置的快照规则
执行save或者bgsave命令
执行flushall命令
执行主从复制操作 (第一次）

自定义配置触发RDB快照 <redis.conf文件>

save "" # 不使用RDB存储不能主从

save 900 1 # 表示15分钟（900秒钟）内至少1个键被更改则进行快照。

save 300 10 # 表示5分钟（300秒）内至少10个键被更改则进行快照。

save 60 10000 # 表示1分钟内至少10000个键被更改则进行快照。

RDB执行流程

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

RDB文件结构：

RDB的优缺点：

优点：RDB是二进制压缩文件，占用空间小，便于传输（传给slaver）主进程fork子进程，可以最大化Redis性能，主进程不能太大，复制过程中主进程阻塞

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

二，AOF

AOF（append only file）是Redis的另一种持久化方式。Redis默认情况下是不开启的。开启AOF持久化后 Redis 将所有对数据库进行过写入的命令（及其参数）（RESP）记录到 AOF 文件，以此达到记录数据库状态的目的，这样当Redis重启后只要按顺序回放这些命令就会恢复到原始状态了。 AOF会记录过程，RDB只管结果。

AOF配置开启：

AOF原理：

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

命令传播、缓存追加、文件写入和保存。

命令传播：

当一个 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 文件保存到磁盘中。

AOF 保存模式

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

AOF_FSYNC_NO ：不保存。
AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。（默认）
AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。（因为是Save主进程执行，会导致阻塞，所以不推荐）

三，AOF工作原理

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

比如现在 set user:1:fyhhhhhh name test1 , set user:1:fyhhhhhh name test2,会对两条重写，这种情况下保存之后一条数据即可

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

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

不过，使用子进程也有一个问题需要解决：因为子进程在进行 AOF 重写期间，主进程还需要继续处理命令，而新的命令可能对现有的数据进行修改，这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。为了解决这个问题， Redis 增加了一个 AOF 重写缓存，这个缓存在 fork 出子进程之后开始启用， Redis 主进程在接到新的写命令之后，除了会将这个写命令的协议内容追加到现有的 AOF 文件之外，还会追加到这个缓存中。也就是说重写是对原有和新入同时进行的

AOF重写工作原理：

AOF重写的触发原理：

1、配置触发

在redis.conf中配置

2、执行bgrewriteaof命令

四，混合持久化

开启混合持久化：

AOF文件的载入与还原：

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

AOF & RDB对比

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

应用场景选择：