Redis 持久化

云三木

已于 2022-09-12 14:20:41 修改

阅读量303

点赞数

分类专栏： Redis 文章标签： redis 缓存

于 2022-08-10 18:32:44 首次发布

本文链接：https://blog.csdn.net/weixin_43844718/article/details/126269452

版权

Redis 专栏收录该内容

9 篇文章 2 订阅

订阅专栏

Redis 系列笔记：

第一篇:Redis 基础命令
 第二篇:Redis 常见应用场景
 第三篇:Redis Cluster集群搭建
 第四篇:Redis 主从及哨兵搭建
 第五篇:Redis 主从及集群
 第六篇:Redis 持久化
 第七篇:Redis 分布式锁
 第八篇:Redis 底层数据存储结构
 第九篇:Redis 面试常问问题

Redis的持久化

redis的持久化有两种aof和rdb，默认情况下，使用快照RDB的持久化方式。
配置可以在redis.conf文件中查看或者通过命令查看

1. RDB

1.1. 配置

命令查看：config get 配置项

127.0.0.1:6379> config get save
1) "save"
2) "900 1 300 10 60 10000"

配置文件redis.conf中RDB相关策略

save 900 1	#900秒内，如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内，如果超过10个key被修改，则发起快照保存
save 60 10000 #60秒内，如果1万个key被修改，则发起快照保存

dbfilename dump.rdb # RDB 文件名称

rdbcompression yes(|no) # rdb 文件中压缩启用配置，基本语法格式; 如果 rdbcompression 配置为 yes，那么即代表 redis 进行 RDB 文件生成中，如果遇到字符串对象并且其中的字符串值占用超过 20 个字节，那么就会对字符串进行 LZF 算法进行压缩。

stop-writes-on-bgsave-error yes(|no) # 如果进行 RDB 备份文件生成过程中，遭遇错误，是否停止 redis 提供写服务，以警示用户 RDB 备份异常，默认是开启状态。

dir ./ # dir 配置的是 rdb 文件存放的目录，默认是当前目录。

rdbchecksum yes(|no) # 是否使用 CRC64 校验算法校验 RDB 文件是否发生损坏，默认开启状态，如果你需要提升性能，可以选择性关闭。

1.2. 触发机制

触发RDB持久化过程分为 手动触发 和 自动触发

1.2.1 手动触发

使用save和bgsve两个命令触发RDB持久化。

save：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞。(save命令已经废弃)
bgsave：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

1.2.2 自动触发

1）使用redis.conf中save相关配置，如“save m n ” 表示m秒内数据集存在n次修改时，自动触发bgsave
2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点。
3）执行debug reload 命令重新加载redis时，也会自动触发save操作
4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave.

1.3. 数据恢复

注意：数据恢复会优先加载 aof 文件，如果要记载 rdb 数据需要先将 appendonly 配置改为 no

保证安装目录下的dump.rdb存在,重新启动就能加载到数据，更复杂的情况这里就不多说了

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/redis/bin"
127.0.0.1:6379> 
[root@VM-0-12-centos bin]# ls
dump.rdb redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis.conf  redis-sentinel  redis-server
[root@VM-0-12-centos bin]#

1.4. 优缺点

优点：

RDB文件是一个紧凑的二进制压缩文件，是Redis在某个时间点的全部数据快照。所以使用RDB恢复数据的速度远远比AOF的快，非常适合备份、全量复制、灾难恢复等场景。

缺点：

每次进行bgsave操作都要执行fork操作创建子经常，属于重量级操作，频繁执行成本过高，所以无法做到实时持久化，或者秒级持久化。
由于Redis版本迭代问题，存在不同格式的RDB版本，有可能出现低版本的RDB格式无法兼容高版本RDB文件的问题。

2. AOF

AOF是每次写命令追加写入日志中，主要作用是解决了数据持久化的实时性。
AOF的持久化有三步：命令写入（append）、文件同步（sync）、文件重写（rewrite）。

2.1. 配置

redis.conf中AOF相关配置策略:

appendonly yes # 把 no 改为 yes

appendfilename "appendonly.aof" # 存储文件名

# 策略配置
# always: 每次操作都会立即写入aof文件中
# everysec（默认）: 每秒持久化一次，默认
# no: 不主动进行同步操作，默认30s一次
appendsync always|everysec|no # 调用 fsync 函数，将缓冲区里面的命令写入到硬盘。

# 自动触发AOF重写配置策略。如下所示：修改 Redis 配置文件，让服务器自动执行 BGREWRITEAOF 命令。
# 该配置项表示：触发重写所需要的 aof 文件体积百分比，只有当 aof 文件的增量大于 100% 时才进行重写，也就是大一倍。
# 比如，第一次重写时文件大小为 64M，那么第二次触发重写的体积为 128M，第三次重写为 256M，以此类推。如果将百分比值设置为 0 就表示关闭 AOF 自动重写功能。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #表示触发AOF重写的最小文件体积,大于或等于64MB自动触发。

2.2. 触发机制

2.2.1. 命令写入（append）触发机制

执行修改命令后保存至缓冲区等待 sync 同步到文件中

2.2.2. 文件同步（sync）触发机制

根据配置文件中的appendsync 参数配置触发

2.2.3. 重写（rewrite）触发机制

Rewrite原理 : 重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，这点和快照有点类似。

AOF文件的重写过程的触发，由上面配置的rewrite参数决定。可以手动触发和自动触发。

2.2.3.1. 手动触发

通过使用bgrewriteaof命令触发AOF的重写机制。

2.2.3.2. 自动触发

根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机，当两个条件同时满足时，就会触发重写。

流程图如下：

2.3. 数据恢复

保证安装目录下的appendonly.aof存在,重新启动就能加载到数据。
当不小心执行了 flushall清除了所有的数据后，打开 appendonly.aof 的文件
删除末尾的

*2
$6
SELECT
v3
flushall
[root@VM-0-12-centos bin]# redis-check-aof appendonly.aof # 最好利用 redis-check-aof 这个工具来检测一下你修改过后的 AOF 文件是否正常，以防启动恢复数据的时候出错
AOF analyzed: size=100, ok_up_to=100, diff=0
AOF is valid