Redis（三） 持久化 RDB+AOF

哈喽，大家好，我是有勇气的牛排（全网同名）

有问题的小伙伴欢迎在文末评论，点赞、收藏是对我最大的支持！！！。

官方文档：https://redis.io/docs/management/persistence/

1 RDB持久化

1.1 官方介绍：

RDB (Redis DataBase) 持久性以指定的时间间隔执行数据集的时间点快照，这个快照文件就称为RDB（dump.rdb）,在恢复的时候将快照文件读会到内存即可。

在保存快照的时候，它是备份全量快照，也就是把内存中的所有数据都记录到磁盘中。

配置

config get requirepass

config get port

启动

redis-server /usr/local/redis/redis.conf
redis-cli -a 123456

1.2 配置文件

1.2.1 Redis 6.0.16以下版本

语法：save m n

描述：如果m秒内数据集存在n次修改时，自动触发bgsave

# 每隔900s(15min), 如果超过1个key发生了变化，就写一份新的RDB文件
save 900 1

1.2.2 Redis 6.2/7.0以后版本

语法：save [ ...]

Reids将会再如下两种情况保存快照：

• 超过给定的时间
• 对数据库操作超过给定次数

# 禁用快照 空字符串
save ""

# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 change was performed
#   * After 300 seconds (5 minutes) if at least 100 changes were performed
#   * After 60 seconds if at least 10000 changes were performed
# 例如
save 3600 1 300 100 60 10000

1.3 操作步骤

1.3.1 自动操作

Redis7

# 5s内有2次修改 则保存
save 5 2

# 504 自定义保存路径
dir /usr/local/redis/data

# 481 自定义保存文件名
dbfilename dump.rdb

1.3.2 手动触发

1、save

在住程序包中执行会阻塞当前redis服务器，直到持久化工作完成，在执行save命令期间，Redis不能处理其他命令，线上禁止使用。

2、bgsave

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

3、lastsave

获取上一次成功快照时间

1.4 恢复数据

• 将备份文件（dump.rdb）移动到redis安装目录并启动服务即可。
• 一定要分机隔离，避免新数据丢失。

1.5 RDB优缺点

1.5.1 优点

• 适合大规模数据恢复
• 按照业务定时备份
• 对数据完整性和一致性要求不高
• RDB文件在内存中的加载速度要比AOF要快的多

1.5.2 缺点

• 在一定间隔时间做一次备份，如果redis意外down，就会丢失从当期至最近一次快照时间的数据。
• 内存数据全量同步，如果数据量太大会导致I/O验证影响服务器性能。
• RDB依赖于主进程fork，在跟打的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候，内存中的数据备克隆了一份，大致2倍的膨胀性，需要考虑。

1.6 检查修复dump.rdb文件

修复命令

redis-check-rdb /usr/local/redis/redis.conf

1.7 哪些情况会触发RDB快照

• 配置文件中默认的快照配置
• 手动save/bgsave命令
• 执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空白。
• 执行shutdown，且没有开启AOF持久化
• 主从复制比时，主节点自动触发

1.8 禁用快照

修改配置

save ""

命令修改

redis-cli config set save ""

1.9 RDB优化配置项

# yes(默认, 推荐)
# no: 表示不在户数据不一致or其他手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求。
stop-writes-on-bgsave-error yes

# yes(默认, 推荐): 对于存储到磁盘中的快照，可以设置是否进行压缩存储。
# 如果是：redis则会采用LZF算法进行压缩。
rdbcompression yes

# yes(默认, 推荐): 在存储快照后，还可以让redis使用CRC64算法进行数据校验，但是这样做会增大10%的性能消耗，如果希望性能最大提升，则可以关闭。
rdbchechsum yes

# 在没有持久性的情况下删除复制中使用的RDB文件启动
# 默认为no
rdb-del-sync-files no

2 AOF（Append only file）持久化

2.1 AOF介绍

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

默认情况下，redis没有开启AOF。

保存文件为：appendonly.aof

2.2 AOF持久化工作流程

1. Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2. 在这些命令到达Redis Server以后，并不是直接写入AOF文件，而是会将这些玩命令先放入到AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令到达一定量以后再写入磁盘，避免频繁的IO操作。
3. AOF缓冲区会根据AOF缓冲区同步文件的三种写会策略，将命令写入磁盘上的AOF文件。
4. 随着写入AOF内容的增加，为避免文件膨胀，会根据规则进行命令合并（又称AOF重写），从而起到AOF文件压缩的目的。
5. 当Redis Server服务器重启的时候，就会从AOF文件载入数据。

2.3 AOF的三种写回策略

Always：同步回写，每个命令执行完立刻同步地将日志写会磁盘。

everysec ：每秒写回，每个命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1s把缓冲区的内容写入磁盘。

no：操作系统控制写回，每隔命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

# 1379
appendonly everysec

配置项	写回时机	优点	缺点
Always	同步写回	可靠性高，数据基本不丢失	每个写命令都要落盘，性能影响大
Everysec	每秒写回	性能适中	宕机时丢失1s内的数据
No	操作系统控制写回	性能好	宕机时丢失的数据较多

2.4 配置文件

在redis6中只用单个AOF文件，但是在redis7中，AOF被拆分为了3个文件（Multi Part AOF设计）

• base：一般由子进程通过重写产生，该文件最多只有一个。
• incr：一般会再AOFRW开始执行时被创建爱，每次AOFRW成功完成时，本次AOFRW之前对应的BASE和INCR AOF，都将变为HISTORY，HISTORY类型的AOF会被Redis自动删除。
• history

redis6

# AOF开启
appendonly yes

# 写回策略
appendfsync everysec

# 保存路径 与RDB一样
dir /usr/local/redis/data

# 文件名
appenddirname "appendonly.aof"

reids7

# AOF开启
appendonly yes

# 写回策略
appendfsync everysec

# RDB数据保存路径
dir /usr/local/redis/data

# AOF保存路径(自动拼接dir)
# 1412 {dir}/appendonlydir
appenddirname "appendonlydir"

# 1406 文件名
appenddirname "appendonly.aof"

Append only mode模块

# 是否开启aof
appendonly yes

# 文件名称
appendfilename "appendonly.aof"

# 同步方式: everysec/always/no
appendfsync "everysec"

# aof重写期间是否同步
no-appendfsync-on-wirte no

# 重写触发配置、文件重写策略
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

2.5 AOF文件修复

问题：AOF文件没有写完，宕机等情况

异常修复命令

redis-check-aof --fix ***.aof

2.6 优缺点

优点

• 更好的保护数据不丢失、性能高、可做紧急恢复

缺点

• 就相同数据集的数据而言，AOF文件要远大于rdb文件，回复速度慢于rdb
• aof运行效率要慢于rdb，每秒同步策略效率要好。

2.7 AOF重写

1. 在重写开始前，redis会创建一个"重写子进程"，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩写入到一个临时文件中。
2. 与此同时，主进程会将新收到的指令一遍积累到内存缓冲区中，一遍继续写入原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写的过程中出现意外。
3. 当“重写子进程”，完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中的写指令追加到新AOF中
4. 当追加结束后，redis就会用新AOF文件来替换旧AOF文件，之后再有新的指令，就会追加到新的AOF文件中。
5. 重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

3 RDB-AOF混合持久化

默认在同时开启rdb和aof持久化时，重启时只会加载aof文件，不会加载rdb文件。

开启混合持久化方式后：

• RDB快照做全量持久化
• AOF做增量持久化

配置

# 开启混合持久化配置
aof-use-rdb-preamble yes

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或者手动触发重写的时候，将最新的数据存储为RDB记录。这样的话重启服务的时候会从RDB何AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。

4 纯缓存模式(同时关闭RDB+AOF)

# 禁用RDB
# 禁用后仍然可以使用save、bgsave生成RDB文件
save ""

# 禁用AOF
# 禁用后，仍然可以使用 bgrewrtteaof 生成aof文件
appendonly no

参考地址：

https://www.bilibili.com/video/BV13R4y1v7sP（尚硅谷~阳哥）