Redis 持久化-RDB和 持久化-AOF 的详细介绍以及区别

尘觉
187 阅读9分钟

Redis 持久化-RDB

官方资料

在线文档: redis.io/topics/pers…

持久化方案

  1. RDB（Redis DataBase）

  2. AOF（Append Of File）

RDB 是什么?

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

RDB 持久化流程

RDB 及其执行流程

在这里插入图片描述

对上图的解读

具体流程如下：

  1. redis 客户端执行bgsave 命令或者自动触发bgsave 命令；

  2. 主进程判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回；

  3. 如果不存在正在执行的子进程，那么就fork 一个新的子进程进行持久化数据，fork 过程是阻塞的，fork 操作完成后主进程即可执行其他操作；

  4. 子进程先将数据写入到临时的rdb 文件中，待快照数据写入完成后再原子替换旧的rdb文件；

  5. 同时发送信号给主进程，通知主进程rdb 持久化完成，主进程更新相关的统计信息

小结

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

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

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

Fork&Copy-On-Write

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

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

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

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、配置的如图

在这里插入图片描述

2、注意理解这个时间段的概念.

在这里插入图片描述

3、如果我们没有开启save 的注释, 那么在退出Redis 时, 也会进行备份, 更新dump.db

save VS bgsave

1、save ：save 时只管保存，其它不管，全部阻塞。手动保存, 不建议。

2、bgsave：Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求。

3、可以通过lastsave 命令获取最后一次成功执行快照的时间(unix 时间戳) , 可以使用工具转换tool.lu/timestamp/

flushall

1、执行flushall 命令，也会产生dump.rdb 文件, 数据为空.

2、Redis Flushall 命令用于清空整个Redis 服务器的数据(删除所有数据库的所有key) 在这里插入图片描述

在这里插入图片描述

Save

1、格式：save 秒钟写操作次数, 如图

在这里插入图片描述

在这里插入图片描述

2、RDB 是整个内存的压缩过的Snapshot，RDB 的数据结构，可以配置复合的快照触发条件，

stop-writes-on-bgsave-error

1、配置如图

在这里插入图片描述

2、当Redis 无法写入磁盘的话(比如磁盘满了), 直接关掉Redis 的写操作。推荐yes

rdbcompression

1、配置如图

在这里插入图片描述

2、对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis 会采用LZF 算法进行压缩。

3、如果你不想消耗CPU 来进行压缩的话，可以设置为关闭此功能, 默认yes

rdbchecksum

在这里插入图片描述

2、在存储快照后, 还可以让redis 使用CRC64 算法来进行数据校验，保证文件是完整的

3、但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能, 推荐yes

动态停止RDB

1、动态停止RDB：redis-cli config set save ""

2、说明: save 后给空值，表示禁用保存策略

实例演示

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

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

RDB 备份&恢复

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

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

2、看演示

  1. config get dir 查询rdb 文件的目录

在这里插入图片描述

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

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

RDB 持久化小结

优势

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

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

3、节省磁盘空间

4、恢复速度快

在这里插入图片描述

劣势

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

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

Redis 持久化-AOF

官方资料

在线文档: redis.io/topics/pers…

AOF 是什么?

1、AOF(Append Only File)

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

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

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

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

AOF 持久化流程

持久化流程示意图

在这里插入图片描述

解读上图

  1. 客户端的请求写命令会被append 追加到AOF 缓冲区内
  2. AOF 缓冲区根据AOF 持久化策略[always,everysec,no]将操作sync 同步到磁盘的AOF 文件中
  3. AOF 文件大小超过重写策略或手动重写时，会对AOF 文件rewrite 重写，压缩AOF 文件容量
  4. 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，然后重新加载

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述 在这里插入图片描述

同步频率设置

配置位置

在这里插入图片描述

解读上图

  1. appendfsync always始终同步，每次Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好

  2. appendfsync everysec每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

  3. appendfsync no redis 不主动进行同步，把同步时机交给操作系统

如果想要跟深入了解可以参考baijiahao.baidu.com/s?id=174077…

Rewrite 压缩

rewrite 重写介绍

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

重写触发配置

手动触发直接调用bgrewriteaof 命令

在这里插入图片描述

自动触发

在这里插入图片描述

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

相当于

系统载入时或者上次重写完毕时，Redis 会记录此时AOF 大小，设为base_size,

如果Redis 的AOF 当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis 会对AOF 进行重写

AOF 持久化小结

优势

1、备份机制更稳健，丢失数据概率更低。

2、可读的日志文本，通过操作AOF 稳健，可以处理误操作

在这里插入图片描述

劣势

1、比起RDB 占用更多的磁盘空间

2、恢复备份速度要慢

3、每次读写都同步的话，有一定的性能压力

RDB 还是AOF?

1、官方文档地址: redis.io/topics/pers… 在这里插入图片描述 2、官方推荐两个都启用

3、如果只做缓存：如果你只希望你的数据在服务器运行的时候存在, 你也可以不使用任何持久化方式

avatar
文章
阅读
粉丝