Redis之持久化操作

创始人

2024-05-31 14:20:50

0次

一、简介

二、RDB

1、自动触发

2、手动触发

3、RDB 的优点和缺点

三、AOF

1、AOF的工作流程

2、AOF的配置

3、AOF的优点和缺点

4、俩种持久化的方式如何选择？

一、简介

1、什么是持久化？

持久化是指将内存中的数据同步到磁盘中，避免由于一些异常而导致redis中的数据丢失。

当 redis 实例重启时，可利用之前持久化的文件进行恢复

2、redis持久化的俩种方式

RDB（全量保存）
AOF（增量保存）

二、RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。这个快照文件就是 RDB 文件(dump.rdb)

RDB 实现持久化的方式有俩种：

自动触发
手动触发

在讲这俩种方式之前，先来解释一下关于RDB持久化的配置：

################################ SNAPSHOTTING  ################################# 当 3600s 内有一个 key 发生变化就会执行一次持久化
# 当 300s 内有 100 个 key 发生变化时就会执行一次持久化
# 当 60s 内有 10000 个key 发生变化时就会执行一次持久化
#   save ""
save 900 1
save 300 10
save 60 10000# 当硬盘内存满了之后，不会再去执行写入
stop-writes-on-bgsave-error yes#  对于生成的备份文件是否进行压缩
rdbcompression yes# 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，
# 但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能(推荐开启yes)
rdbchecksum yes# 备份的文件名
dbfilename dump.rdb# 在没有持久性的实例中删除复制使用的RDB文件
rdb-del-sync-files no# 备份文件的所在位置。 默认在 redis 启动目录中。/usr/local/bin/ 下`
dir ./

在Redis7之后，进行持久化的时间配置有一些变化：

# save ""
# save 3600 1 300 100 60 10000

1、自动触发

首先修改一下配置

################################ SNAPSHOTTING  ################################
# 在5s内有俩个写操作就会进行一次持久化
save 5 2stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yesdbfilename dump.rdbrdb-del-sync-files nodir /myredis/dumpfiles/

可以通过 config get dir 命令查看 rdb 文件保存的目录：

127.0.0.1:6379> CONFIG GET dir
dir
/myredis/dumpfiles

演示

初始状态下，未执行任何操作，也没有 dump.rdb 文件

当我们 5s 内进行俩次写操作时，就会生成一个 dump.rdb 文件

值得注意的是：当我们执行 FLUSHALL/FLUSHDB/shutdown 命令时，也会生成一个 dump.rdb 文件

那么我们如何使用 dump.rdb 文件恢复数据呢？

其实也不用我们有过多的操作，dump.rdb 文件是和 redis 服务器中的数据实时更新同步的，因此我们可以使用一个定时任务，定时备份最近几天的 dump.rdb 文件，当然，尽量避免 dump.rdb 文件和 redis 服务器在同一台机器上，如果你的 reids服务器gua了，你的 dump文件也没了，那数据就真的没了~

2、手动触发

在 Redis 中提供了俩个命令：save/bgsave 可以手动生成 dump.rdb 文件

（1）save

这个命令大家尽量不要用，因为当执行这个命令时，持久化操作会在主进程执行，会阻塞当前的 redis 的服务器，直到持久化完成。也就是说，在执行 save 命令后，你的redis是无法使用的。

（2）bgsave

bgsave 会以异步的方式进行持久化操作， redis 会调用 fork() ，复制出一个与父进程一样子进程，由子进程来完成持久化操作。不会影响redis的执行。

3、RDB 的优点和缺点

优点

相对于数据集大时，比 AOF 的启动效率更高。
性能最大化，利用 fork 子进程完成持久化操作，主进程不会进行任何的 IO 操作，保证了高性能
节省磁盘空间
恢复速度快

缺点

数据安全性低。 RDB 是间隔一段时间进行持久化，如果持久化之间 Redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

总结

什么时候会触发生成 rdb 文件？

配置文件中手动配置生成配置文件的策略
使用 save/bgsave 命令
使用 FLUSHALL/FLUSHDB/SHUTDOWN 命令
主从复制时，主节点自动触发

RDB 的工作流程：

Redis 调用 fork. 同时拥有父进程和子进程。
子进程将数据集写入到一个临时 RDB 文件中。
当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

三、AOF

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

1、AOF的工作流程

（1）客户端的请求写命令会被 append 追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件 rewrite 重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

2、AOF的配置

AOF默认是关闭的，需要手动开启，下面是关于AOF的配置：

############################## APPEND ONLY MODE ###############################
# 改成 yes 开启 AOF 功能
appendonly yes
# 文件名
appendfilename "appendonly.aof"
# ===============================以下就是 AOF 的三种策略================================# 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
# appendfsync always# 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync everysec# redis不主动进行同步，把同步时机交给操作系统。
# appendfsync no

注意：

在 Redis7 之后，文件名、文件位置都发生了比较大的变化。

文件位置：

Redis7 以前，aof文件的保存位置和 rdb文件一致

在 Redis7 之后，采用 dir + appenddirname 的方式确定 aof 文件的位置

# aof文件最终的位置：/myredis/aoffiles
dir /myredis/
appenddirname "aoffiles"

文件名：

Redis7采用 Multi Part Aof 的设计 , 将一个 aof 文件拆分成了三个文件，文件名前缀依然由 appendfilename 指定。

# aof 文件会被拆分成以下三个文件
# - appendonly.aof.1.base.rdb as a base file.
# - appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof as incremental files.
# - appendonly.aof.manifest as a manifest file.appendfilename "appendonly.aof"# 拆分的三个文件都会保存在 appendonlydir 目录下
appenddirname "appendonlydir"

演示