Redis 持久化-RDB

官方资料

在线文档: https://redis.io/topics/persistence

持久化方案

RDB（Redis DataBase）
AOF（Append Of File）

RDB 是什么?

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就Snapshot 快照，恢复时将快照文件读到内存

RDB 持久化流程

RDB 及其执行流程

在这里插入图片描述

对上图的解读

具体流程如下：

redis 客户端执行bgsave 命令或者自动触发bgsave 命令；
主进程判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回；
如果不存在正在执行的子进程，那么就fork 一个新的子进程进行持久化数据，fork 过程是阻塞的，fork 操作完成后主进程即可执行其他操作；
子进程先将数据写入到临时的rdb 文件中，待快照数据写入完成后再原子替换旧的rdb文件；
同时发送信号给主进程，通知主进程rdb 持久化完成，主进程更新相关的统计信息

小结

整个过程中，主进程是不进行任何IO 操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复, 且对于数据恢复的完整性不是非常敏感，那RDB 方式要比AOF 方式更加的高效
RDB 的缺点是最后一次持久化后的数据可能丢失

解读

-如果你是正常关闭Redis , 仍然会进行持久化, 不会造成数据丢失

-如果是Redis 异常终止/宕机, 就可能造成数据丢失

Fork&Copy-On-Write

1、Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等) 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

2、在Linux 程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec 系统调用，

出于效率考虑，Linux 中引入了"写时复制技术即: copy-on-write" , 有兴趣的参考: https://blog.csdn.net/Code_beeps/article/details/92838520

3、一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

RDB 配置

dump.rdb 文件

介绍

在redis.conf 中配置文件名称, 默认为dump.rdb

在这里插入图片描述

如何配置

1、默认为Redis 启动时命令行所在的目录下

如图

在这里插入图片描述

进入到/usr/local/bin 目录下, 启动Redis, 这个./ 就是/usr/local/bin , 如果你在/root/ 目录下启动Redis , 那么./ 就是/root/ 下了, 这点请注意一把

在这里插入图片描述

2、rdb 文件的保存路径, 也可以修改, 比如: dir “/root/” , 演示一下…

实例演示

1、需求: 如果Redis 的key 在30 秒内, 有5 个key 变化, 就自动进行RDB 备份.

在这里插入图片描述

RDB 备份&恢复

1、关于RDB 备份&恢复, 老韩要说的

先说明：Redis 可以充当缓存, 对项目进行优化, 因此重要/敏感的数据建议在Mysql要保存一份
从设计层面来说, Redis 的内存数据, 都是可以重新获取的(可能来自程序, 也可能来自Mysql)
因此我们这里说的备份&恢复主要是给大家说明一下Redis 启动时, 初始化数据是从dump.rdb 来的, 这个机制.

2、看演示

config get dir 查询rdb 文件的目录

在这里插入图片描述

将dump.rdb 进行备份, 如果有必要可以写shell 脚本来定时备份可以参考Linux专栏的大数据定制篇最后的综合案例, 这里简单处理

在这里插入图片描述

RDB 持久化小结

优势

1、适合大规模的数据恢复

2、对数据完整性和一致性要求不高更适合使用

3、节省磁盘空间

4、恢复速度快

在这里插入图片描述

劣势

1、虽然Redis 在fork 时使用了写时拷贝技术(Copy-On-Write), 但是如果数据庞大时还是比较消耗性能。

2、在备份周期在一定间隔时间做一次备份，所以如果Redis 意外down 掉的话(如果正常关闭Redis, 仍然会进行RDB 备份, 不会丢失数据), 就会丢失最后一次快照后的所有修改

Redis 持久化-AOF

官方资料

在线文档: https://redis.io/topics/persistence

AOF 是什么?

1、AOF(Append Only File)

2、以日志的形式来记录每个写操作(增量保存)，将Redis 执行过的所有写指令记录下来(比如set/del 操作会记录, 读操作get 不记录) [后面详细讲解]

3、只许追加文件但不可以改写文件

4、redis 启动之初会读取该文件重新构建数据

5、redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF 持久化流程

持久化流程示意图

在这里插入图片描述

解读上图

客户端的请求写命令会被append 追加到AOF 缓冲区内
AOF 缓冲区根据AOF 持久化策略[always,everysec,no]将操作sync 同步到磁盘的AOF 文件中
AOF 文件大小超过重写策略或手动重写时，会对AOF 文件rewrite 重写，压缩AOF 文件容量
Redis 服务重启时，会重新load 加载AOF 文件中的写操作达到数据恢复的目的

AOF 开启

1、在redis.conf 中配置文件名称，默认为appendonly.aof

在这里插入图片描述

2、AOF 文件的保存路径，同RDB 的路径一致。

3、AOF 和RDB 同时开启，系统默认取AOF 的数据

4、实验, 当开启AOF 后, Redis 从AOF 文件取数据.

关闭redis

在这里插入图片描述

AOF 实例演示

需求：开启AOF 机制, 使用AOF 机制进行Redis 内存数据的备份和恢复

确保Redis 开启了AOF 机制

在这里插入图片描述

AOF 启动/修复/恢复

基本说明

AOF 的备份机制和性能虽然和RDB 不同, 但是备份和恢复的操作同RDB 一样, 都是拷贝备份文件, 需要恢复时再拷贝到Redis 工作目录下，启动系统即加载

正常恢复

1、修改默认的appendonly no，改为yes

2、将有数据的aof 文件定时备份, 需要恢复时, 复制一份保存到对应目录(查看目录：configget dir)

3、恢复：重启redis 然后重新加载

4、这个就不演示了, 和前面RDB 备份/恢复机制类似

异常恢复

1、如遇到AOF 文件损坏，通过/usr/local/bin/redis-check-aof --fix appendonly.aof 进行恢复

2、建议先: 备份被写坏的AOF 文件

3、恢复：重启redis，然后重新加载

在这里插入图片描述

同步频率设置

配置位置

在这里插入图片描述

解读上图

appendfsync always始终同步，每次Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync no redis 不主动进行同步，把同步时机交给操作系统

如果想要跟深入了解可以参考https://baijiahao.baidu.com/s?id=1740774723808931509&wfr=spider&for=pc这篇文章

Rewrite 压缩

rewrite 重写介绍

AOF 文件越来越大，需要定期对AOF 文件进行重写达到压缩
旧的AOF 文件含有无效命令会被忽略，保留最新的数据命令, 比如set a a1 ; set a b1 ;set a c1; 保留最后一条指令就可以了
多条写命令可以合并为一个, 比如set a c1 b b1 c c1
AOF 重写降低了文件占用空间
更小的AOF 文件可以更快的被redis 加载

重写触发配置

手动触发直接调用bgrewriteaof 命令

在这里插入图片描述

自动触发

在这里插入图片描述

auto-aof-rewrite-min-size: AOF 文件最小重写大小, 只有当AOF 文件大小大于该值时候才能重写, 默认配置64MB
auto-aof-rewrite-percentage: 当前AOF 文件大小和最后一次重写后的大小之间的比率等于或者大于指定的增长百分比，如100 代表当前AOF 文件是上次重写的两倍时候才重写