【Redis】持久化

本文详细探讨了Redis的两种持久化方式——RDB(定期快照)和AOF(逐条记录),包括它们的备份与恢复机制、优缺点、工作流程以及混合持久化的实现。重点介绍了RDB和AOF在数据恢复、写回策略和性能上的特点。
摘要由CSDN通过智能技术生成

一、RDB

RDB持久化是以指定的时间间隔,将内存中的数据集快照写入磁盘。其保存的文件是 dump.rdb文件。

1.1、RDB的自动备份与手动备份

1.1.1、自动备份

RDB触发备份
将配置修改如下

save 5 2
dir /myredis/dumpfiles
dbfilename dump.rdb

redis中执行两次操作时会保存一次dump.rdb文件。
此时若使用FLUSHDB,redis会保存空数据到dump.rdb
此时若使用SHUTDOWN,redis会把当前的数据保存到dump.rdb

RDB 恢复备份
  重启redis时,redis会通过加载redis.conf中的dump.rdb的文件路径来恢复redis数据库。
:不可以把备份文件dump.rdb和生产redis服务器放在同一台机器,必须分开各自存储,以防生产机物理损坏后备份文件也挂了。

1.1.2、手动备份

  Redis手动生成了两个命令来生成RDB文件,分别是SAVEBGSAVE,其中一般使用BGSAVE
  由于使用SAVE会在主程序中执行会阻塞当前redis服务器,直到持久化工作完成。执行SAVE命令期间,Redis不能处理其他命令,所以在线上禁止使用SAVE
  使用BGSAVE会在后台异步进行快照操作,不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程。
  并且还可以使用LASTSAVE命令获取最后一次成功执行快照的时间。

1.2、RDB优点

  • RDB非常适合灾难恢复,它是一个可以传输到远程数据中心的压缩文件。
  • RDB最大限度地提高了Redis的性能,因为Redis父进程为了持久化而需要做的唯一工作就是派生一个将所有其余工作都完成的子进程。父进程永远不会执行磁盘I/O或类似操作。
  • 与AOF相比,RDB允许使用大数据集更快地重启。
  • 在副本上,RDB支持重启和故障转移后的部分重新同步。

1.3、RDB缺点

  • 如果Redis由于任何原因没有在正常关闭的情况下停止工作,那最新分钟的数据可能会丢失。
  • 内存数据的全量同步,如果数据量太大会导致I/O严重影响服务器性能。
  • RDB需要经常fork()以便使用子进程在磁盘上持久化。如果数据集很大,fork()会很耗时。

1.4、RDB快照

  触发RDB快照的操作有:

  • 配置文件中默认的快照配置
  • 手动SAVE/BGSAVE命令
  • 执行FLUSHDB/FLUSHALL命令
  • 执行SHUTDOWN且没有设置开启AOF持久化
  • 主从复制时,主节点自动触发

禁用快照的方法:

  • 动态停止RDB保存规则的方法:redis-cli config set save ""
  • 快照禁用,在配置文件redis.conf中修改save ""

1.5、RDB优化配置项

  RDB的优化配置项在配置文件redis.confSNAPSHOTTING模块中

save <seconds> <changes>
# 在规定的时间内或者几次修改后自动保存到磁盘

dbfilename  # dump.rdb的文件名

dir # dump.rdb所在的路径

stop-writes-on-bgsave-error
# 默认为yes,在bgsave报错后停止写入
# no表示在快照写入失败时,也能确保redis继续接受新的写请求。

rdbcompression
# 对于存储到磁盘的快照是否压缩存储。
# yes,redis会使用LZF算法进行压缩
# no,减少CPU在这方面的消耗

rdbchecksum
# 合法性校验
# 默认yes,redis使用CRC64算法进行数据校验
# no,关闭校验,提高性能

rdb-del-sync-files
# 默认no,禁用此选项

二、AOF

  AOF是以日志形式来记录每个写操作,将Redis执行过的所有写指令记录下来,并且只允许追加文件不允许改写文件,在redis启动的时候读取该文件并且将写指令从前往后执行一遍以完成数据的恢复工作。
  默认情况下,redis没有开启AOF,通过appendonly yes来开启。它保存的文件名为appendonly.aof

2.1、AOF工作流程

在这里插入图片描述

序号详细步骤
1客户端会产生请求命令发送至服务端
2命令到达服务端后,并没有直接写入AOF文件,先保存在AOF缓存中,AOF缓存的目的是当这些命令到达一定数量后再写入磁盘,避免频繁的磁盘IO操作
3AOF缓存根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘的AOF文件
4由于AOF文件内容的增加,为了避免膨胀,进行AOF重写完成命令的合并,从而达到AOF文件压缩的目的
5服务端重启后,会从AOF文件载入数据

2.2、AOF写回策略

  AOF有三种写回策略,默认是everysec

配置项写回时机优点缺点
always同步写回可靠性高、数据不丢失每个写命令都要写磁盘,IO量大,性能影响较大
everysec每秒写回性能适中宕机时丢失1秒内的数据
no由操作系统控制写回性能好宕机时丢失的数据较多

2.3、MP-AOF实现

  MP-AOF就是将原来的单个AOF文件拆分成多个AOF文件。AOF的类型有:

  • BASE:基础AOF,由子进程通过重写产生,最多只有一个
  • INCR:增量AOF,一般会在AOFRW开始执行时创建,可能存在多个
  • HISTORY:AOFRW成功完成后,所有的BASEINCR AOF都变成HISTORY,该类型的AOF会被Redis自动删除。

  为了管理这些AOF文件,还引入了manifest文件来追踪管理这些AOF,总的来说,Redis7以后的AOF文件结构如下:

// 几种类型文件的前缀,后面跟着有关序列和类型的附加信息
appendfilename "appendonly.aof"

//新版本增加的目录配置项目
appenddirname "appendonlydir"

//具体文件
1、基本文件
	appendonly.aof.1.base.aof
2、增量文件
	appendonly.aof.1.incr.aof
	appendonly.aof.2.incr.aof
3、清单文件
	appendonly.aof.manifest

2.4、AOF优缺点

优势

  • 使用AOF Redis更加持久,使用每秒fsync策略既可以保证写入性能,也可以减少redis宕机时丢失的数据。
  • AOF日志是一个仅附加的日志,因此不会出现寻道问题,也不会在断电时出现损坏问题,即使日志以写一半的命令结尾,redis-check-aof工具也能轻松修复。
  • Redis能够自动重写AOF,从而减少AOF的磁盘占用空间。
  • 即使使用FLUSHALL命令刷新了所有内容,也可以通过删除AOF中的最新内容来恢复数据。

劣势

  • AOF文件通常比相同数据集的RDB文件大,回复速度慢于RDB
  • AOF运行效率低于RDB,每秒同步策略效率好,不同步的话效率和RDB相同。

2.5、AOF重写机制

  重写机制通过启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。它并不是对源文件进行重新整理,而是直接读取服务器现有的键值对,然后用一条命令去代替之前记录这个键值对的多条命令,生成一个新的文件去替换原来的AOF文件。
触发机制
  手动方式通过命令bgrewriteaof命令触发
  自动方式通过配置文件的选项触发

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 这里表示被重写的aof文件既要达到之前大小的一倍又要超过64mb才会自动重写

  触发重写后,相应AOF文件的序号会增加,例如:

appendonly.aof.1.base.aof
appendonly.aof.1.incr.aof

## 变成

appendonly.aof.2.base.aof
appendonly.aof.2.incr.aof

重写原理

  • 在重写开始前,redis会创建一个“重写子进程”,这个子进程会读取现有的AOF文件,并将其包含的指令分析压缩并写入一个临时文件中。
  • 主进程将新接收到的写指令一边累计到内存缓冲区中,一边继续写入到原有的AOF文件中,保证了AOF文件的可用性,避免在重写过程中出现意外。
  • 当“重写子进程”完成重写工作后,它会给父进程发送一个信号,父进程收到信号后将内存中缓存的写指令追加到新AOF文件中。
  • 追加结束后,redis使用新的aof文件替换旧的aof文件,之后新的写指令都会追加到新的aof文件中。
  • 重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库用命令的方式重写了一个新的aof文件

三、RDB+AOF混合持久化

  结合了RDBAOF的优点,既能快速加载又能避免丢失过多的数据。这种混合方式的具体流程是先使用RDB进行快照存储,然后使用AOF持久化记录所有写操作,当重写策略满足或手动触发重写的时候,将最新的数据存储为新的RDB记录。这样重启服务的时候会从RDBAOF两方恢复数据,兼具了数据完整性和性能。
  简单来说,混合持久化使得AOF=RDB头部+AOF混写

3.1、数据恢复顺序和加载流程

  在RDB和AOF都启用的情况下,AOF的优先级高于RDB,redis会先判断AOF文件是否存在,如果不存在的话才会使用RDB
在这里插入图片描述


四、纯缓存模式

  纯缓存模式是关闭redis服务器的持久化功能从而提高服务器性能的方式。主要方法是同时关闭RDB和AOF

禁用rdb
  修改配置文件参数save "",禁用rdb持久化模式下,我们仍然可以使用命令save、bgsave生成rdb文件

禁用aof
  修改配置文件参数appendonly no,禁用aof持久化模式下,我们仍然可以使用命令bgwriteaof生成aof文件

  • 30
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Rockict_z

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值