redis的持久化

最新推荐文章于 2024-08-21 22:55:52 发布

冧轩在努力

最新推荐文章于 2024-08-21 22:55:52 发布

阅读量1.3k

点赞数 24

分类专栏： redis 文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/m0_72532428/article/details/140586143

版权

redis 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

redis的持久化

Redis ⽀持 RDB 和 AOF 两种持久化机制，持久化功能有效地避免因进程退出造成数据丢失问题，当下次重启时利⽤之前持久化的⽂件即可实现数据恢复。

一、RDB持久化机制

RDB会定期的把我们Redis内存中的所有数据都保存到硬盘中。

RDB有定期保存有两种方式，分为手动触发和自动触发

1.1手动触发

程序员通过redis客户端，执行特定的命令来触发RDB的保存

手动触发有两个指令，分别是save和bgsave

save : 执行save指令的时候，redis就会全力以赴的进行保存操作，此时就会阻塞redis的其他客服端的命令，导致类似于keys的后果，一般不建议使用save
bgsave：bg可理解为background（后面）不会影响redis服务器处理其他客服端的请求和命令

bgsave的非阻塞的实现原理，系统创建子进程来，让子进程去执行bgsave后续的保存操作，父进程继续接受客服端发来的命令。

bgsave的执行过程：

如果客服端执行bgsave命令的时候，发现系统中已经存在一个正在执行的bgsave子进程，那么就用该bgsave子进程的保存结果返回给客服端。

如果客服端执行bgsave命令的时候，发现此时没有正在执行bgsave的子进程，那么就通过fork（）这样的系统调用创建出一个子进程，用于执行bgsave的保存操作。

子进程负责进行写文件，父进程继续接受客服端的请求，继续正常提供服务。

当子进程完成整体的持久化过程之后，就会通知父进程，任务完成了，父进程就会更新一些统计信息。然后子进程就可以结束销毁了。

如图：
在这里插入图片描述
RDB文件是保存在redis的默认工作目录中的，在配置文件中可以找到默认工作目录

配置文件在/etc/redis/redis.conf中

sudo vim /etc/redis/redis.conf

在这里插入图片描述

RDB文件默认名字：dump.rdb

查看该目录：

可以发现RDB文件保存在这。

redis服务器默认就是开启rdb的。

RDB文件时二进制文件，在保存的时候会先通过压缩，然后再存储，该过程会消耗CPU资源，但能节省存储空间。
在这里插入图片描述
注意：该文件中的内容不要随便修改，一旦把数据格式改坏了，那就会导致后续redis服务器重新启动的时候出错，因为重启时会尝试加载这个RDB文件，如果发现格式错误，就可能会导致加载数据失败。

RDB文件的检查工具：
在这里插入图片描述

RDB持久化操作是可以多次触发的原因

当执行生成RDB镜像操作的时候，此时就会把要生成的快照数据，先保存在一个临时文件中，当这个快照生成完毕之后，在删除之前的RDB文件，把新生成的临时的RDB文件名字改成刚才的dump.rdb文件。

1.2自动触发

①自动触发在满足条件的情况下才会发生，配置文件中有RDB自动触发的条件，该条件可修改。
在这里插入图片描述
默认条件是，900秒内修改一次或300秒内修改10次或60秒内修改10000次，时间和次数需要同时满足才会触发。

当把条件设置为 save ”“，就表示禁止上面的条件生成快照，但后面说到的两个条件，不受影响。

注意：

虽然该条件可以修改，但是不能将条件修改得频繁触发，因为每次触发生成一次快照的成本都比较高。
也正因为如此RDB生成的不能太频繁，就导致了快照中的数据和实际的数据情况可能存在一定的偏差。

②自动触发还可以通过shutdown命令（redis中的一个命令）关闭redis服务器，也会触发（service redis-server restart）

③redis进行主从复制的时候，主节点也会自动生成RDB快照，然后把RDB快照文件内容传输给从节点（后面博客详细说明）

1.3利用RDB文件恢复redis中的内容

redis在关闭以后，内存中的内容就都释放了，当再重启的时候想要恢复原来的内容那么就需要读取RDB文件中的数据来恢复。

演示：

首先我们先创建三条key-value值，然后使用bgsave命令将它们保存到RDB文件中。
在这里插入图片描述
然后让redis服务器重启

最后登录redis，查看结果：

可以发现和我们预期的结果一样。

注意：

当我们未使用bgsave命令且自动触发条件未满足，此时使用了kill -9 命令让redis服务器异常终止，那么内存中的数据未来得及保存到RDB文件中，该数据就会丢失。
在执行完快照操作以后，前RDB文件和现RDB文件不是同一个文件，因为它们的inode不同。

当我们把RDB文件的部分改坏了，redis启动时使用该二进制文件得到的结果是不可预期的，那么redis服务器可能会不能够启动，启动了以后数据也可能是错误的。

1.4 RDB的优缺点

优点：

RDB 是⼀个紧凑压缩的⼆进制⽂件，代表 Redis 在某个时间点上的数据快照。⾮常适⽤于备份，全量复制等场景。⽐如每 6 ⼩时执⾏ bgsave 备份，并把 RDB ⽂件复制到远程机器或者⽂件系统中（如 hdfs）⽤于灾备。
Redis 加载 RDB 恢复数据远远快于 AOF 的⽅式。

缺点：

RDB ⽅式数据没办法做到实时持久化 / 秒级持久化。因为 bgsave 每次运⾏都要执⾏ fork 创建⼦进程，属于重量级操作，频繁执⾏成本过⾼。
RDB ⽂件使⽤特定⼆进制格式保存，Redis 版本演进过程中有多个 RDB 版本，兼容性可能有⻛险。

二、AOF的持久化机制

以独⽴⽇志的⽅式记录每次写命令，重启时再重新执⾏ AOF ⽂件中的命令达到恢复数据的⽬的。AOF 的主要作⽤是解决了数据持久化的实时性，⽬前已经是 Redis 持久化的主流⽅式。理解掌握好 AOF 持久化机制对我们兼顾数据安全性和性能⾮常有帮助。

2.1使用AOF

AOF默认是关闭状态的，想用使用我们需要去配置文件手动开启：

将appendonly 设置为yes即可，appendfilename 代表的是AOF文件的默认名称
在这里插入图片描述
此时将RDB文件删除掉，然后重启一下redis服务器：

此时再查看工作目录，可以发现AOF文件已经存在了：

现在我们插入几条数据：

然后查看AOF中的内容：

可以发现AOF文件中保存的都是我们输入的指令。

AOF是一个文本文件，每次进行的操作都会被记入到AOF文件中，用一些分隔符进行分隔。

2.2 AOF的执行过程

AOF机制不是直接让工作线程把数据写入硬盘，而是先写入一个内存中的缓冲区中，积累一波数据后，再统一写入硬盘中。

AOF 过程中为什么需要 aof_buf 这个缓冲区？

Redis 使⽤单线程响应命令，如果每次写 AOF ⽂件都直接同步硬盘，性能从内存的读写变成 IO 读写，必然会下降。先写⼊缓冲区可以有效减少 IO 次数，同时，Redis 还可以提供多种缓冲区同步策略，让⽤⼾根据⾃⼰的需求做出合理的平衡。

如果在缓冲区中的数据没来得及写入硬盘，那么数据是否丢了？

是的

所以redis提供了多多种AOF缓冲区同步文件策略，有参数appendfsync控制，不同值的含义如下表：

可配置值	说明
always	命令写⼊ aof_buf 后调⽤ fsync 同步，完成后返回。
everysec	命令写⼊aof_buf 后只执⾏ write 操作，不进⾏ fsync。每秒由同步线程进⾏ fsync。
no	命令写⼊ aof_buf 后只执⾏ write 操作，由 OS 控制 fsync 频率。

系统调⽤ write 和 fsync 说明：

write 操作会触发延迟写（delayed write）机制。Linux 在内核提供⻚缓冲区⽤来提供硬盘 IO 性能。write 操作在写⼊系统缓冲区后⽴即返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区⻚空间写满或达到特定时间周期。同步⽂件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
Fsync 针对单个⽂件操作，做强制硬盘同步，fsync 将阻塞直到数据写⼊到硬盘。
配置为 always 时，每次写⼊都要同步 AOF ⽂件，性能很差，在⼀般的 SATA 硬盘上，只能⽀持⼤约⼏百 TPS 写⼊。除⾮是⾮常重要的数据，否则不建议配置。
配置为 no 时，由于操作系统同步策略不可控，虽然提⾼了性能，但数据丢失⻛险⼤增，除⾮数据重要程度很低，⼀般不建议配置。
配置为 everysec，是默认配置，也是推荐配置，兼顾了数据安全性和性能。理论上最多丢失 1 秒的数据。

2.3 AOF的重写机制

随着命令不断写⼊ AOF，⽂件会越来越⼤，为了解决这个问题，Redis 引⼊ AOF 重写机制压缩⽂件体积。AOF ⽂件重写是把 Redis 进程内的数据转化为写命令同步到新的 AOF ⽂件。

重写后的 AOF 为什么可以变⼩？

进程内已超时的数据不再写⼊⽂件。
旧的 AOF 中的⽆效命令，例如 del、hdel、srem 等重写后将会删除，只需要保留数据的最终版本。
多条写操作合并为⼀条，例如 lpush list a、lpush list b、lpush list 从可以合并为 lpush list a b c。

AOF的重写可分为手动触发和自动触发

手动触发

调用bgrewriteaof命令进行重写。重写的时候不关心aof文件中原来都有什么，只关心内存中最终的数据状态。

**bgrewriteaof命令执行过程：**父进程接收到bgrewriteaof命令时，会调用fork（）系统接口创建一个子进程，子进程只需要把内存中当前的数据获取出来，以AOF的格式写入到一个新的AOF文件中，父进程仍然继续接受客服端发来的命令，当fork后仍然有新的命令发来，那么父进程会维持一个aof_rewrite_buf缓冲区和aof_buf缓冲区，将fork（）后的命令存放到该缓冲区中，再把aof_buf缓冲区中的值写入旧的缓冲区中，等到子进程处理完毕以后，父进程就会把新的AOF文件和aof_rewrite_buf缓冲区合并，再把旧的AOF文件和替换掉，此时保存在磁盘中的AOF文件就是我们要的文件了。
在这里插入图片描述