当前位置:网站首页>redis的持久化方式-RDB和AOF 两种持久化机制

redis的持久化方式-RDB和AOF 两种持久化机制

2022-07-07 23:21:00 beginnerDZ

redis的持久化方式-RDB和AOF两种持久化机制

Redis是基于内存的非关系型K-V数据库,既然它是基于内存的,如果Redis服务器挂了,数据就会丢失。为了避免数据丢失了,Redis提供了持久化,即把数据保存到磁盘。

持久化文件加载流程如下:

请添加图片描述

1.RDB—Redis默认的持久化方式

请添加图片描述

在指定的时间间隔内将内存中的数据集快照写入磁盘

RDB 又分为两种:

  • 一种是同步的,调用 save 命令即可触发 redis 进行 RDB 文件生成备份,但是这是一个同步命令,在备份完成之前,redis 服务器不响应客户端任何请求。
  • 另一种是异步的,调用 bgsave 命令,redis 服务器 fork 一个子进程进行 RDB 文件备份生成,与此同时,主进程依然可以响应客户端请求。

两种触发方式:手动触发(save命令),自动触发(bgsave命令,推荐)
save命令:阻塞当前redis直到rdb持久化完成。若内存实例较大,会造成长时间阻塞,线上环境不建议使用。
bgsave命令:redis进程执行fork命令创建子进程来完成持久化,阻塞时间短(微秒级),save命令的优化。
bgsave触发的条件:
1.在redis-cli中执行shutdown关闭redis服务时,如果没有开启aof持久化,自动执行bgsave命令
2.redis.conf中save m n 若redis在m秒内有n次命令执行则触发
3.从节点刚上线时,触发主节点bgsave命令,然后将生成的rdb文件发送给从节点完成全量复制

fork是linux系统的调用:在当前进程中,fork一个子进程,子进程最初与主进程是共享一份内存区域的。由于主进程不断进行数据的写操作,与子进程存在并发冲突问题。此时,redis采用写时复制技术(cow):
当主进程写操作时,首先会复制一份将要涉及写操作的内存页。然后主进程在新复制的内存页上进行写操作,原有内存页继续供子进程持久化

相关配置

1.save 触发bgsave

save 900 1           # 900秒内执行一次set操作 则持久化1次 
save 300 10         # 300秒内执行10次set操作,则持久化1次
save 60 10000     # 60秒内执行10000次set操作,则持久化1次

2.在redis.conf文件中有设置 默认是文件名和保存路径(默认是 当前启动目录下 就是执行启动命令的目录)

请添加图片描述

  1. stop -writes -on-bgsave-er ror当Redis无法写入磁盘的话(磁盘满了),直接关掉Redis的写操作。推荐yes.

请添加图片描述

4.rdbcompression

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

如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能。推荐yes.

5.rdbchecksum检查完整性

在存储快照后,还可以让redis使用CRC64算法来进行数据校验,校验 RDB 文件是否发生损坏

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

优缺点
  • 优点:

l 灵活设置备份频率和周期。

l 适合大规模的数据恢复,非常适合冷备份,对于灾难恢复而言,RDB 是非常不错的选择。保存在其他云存储上

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

l 节省磁盘空间

l 性能最大化,可以让 Redis 保持高性能。

l 恢复速度快,相比于 AOF 机制,RDB 的恢复速度更更快,更适合恢复数据,特别是在数据集非常大的情况。

  • 缺点:

l Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑

l 在备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改

l 如果数据集很⼤,fork() 可能很耗时,并且如果数据集很⼤且CPU 性能不佳,则可能导致 Redis 停⽌为客⼾端服务⼏毫秒甚⾄⼀秒钟。

​ 所以,RDB 建议在业务低时执行,例如在半夜执行。

2.AOF(Append Only File)

以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录), 只许追加文件但不可以改写文件。

默认不开启,改为yes 打开。保存的路径与rdb一样。

请添加图片描述

AOF和RDB同时开启,系统默认取AOF的数据(数据不会存在丢失)

数据备份恢复和rdb一样: 保存一份文件,当发生错误后,copy过来, 重启redis

异常恢复

修改默认的appendonly no,改为yes

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

备份被写坏的AOF文件

恢复:重启redis,然后重新加载

相关配置

AOF同步频率设置

appendfsync always

始终同步,每次Redis的写入都会立刻记入日志;性能较差但数据完整性比较好

appendfsync everysec

每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。

appendfsync no

redis不主动进行同步,把同步时机交给操作系统。

Rewrite压缩

重写压缩机制,AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩, 只保留可以恢复数据的最小指令集

Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

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

AOF持久化流程

(1)客户端的请求写命令会被append追加到AOF缓冲区内;

(2)AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中;(默认是everysec)

(3)AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;

(4)Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的;

优缺点

  • 备份机制更稳健,丢失数据概率更低。

  • 可读的日志文本,通过操作AOF稳健,可以处理误操作。

  • 比起RDB占用更多的磁盘空间。

  • 恢复备份速度要慢。

  • 每次读写都同步的话,有一定的性能压力。

  • 存在个别Bug,造成恢复不能。

官方推荐两个都启用。

如果对数据不敏感,可以选单独用RDB。

不建议单独用 AOF,因为可能会出现Bug。

如果只是做纯内存缓存,可以都不用。

同时开启时

3.RDB-AOF混合持久化

# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
#   [RDB file][AOF tail]
#
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
aof-use-rdb-preamble yes

开启后

Redis服务器 在执行 AOF重写操作时,就会像执行BGSAVE命令那样,根据数据库当前的状态 生成出 相应的RDB数据,并将这些数据 写入 新建的AOF文件中,至于那些 在AOF重写开始之后 执行的Redis命令,则会继续以协议文本的方式 追加到 新AOF文件的末尾,即已有的RDB数据的后面

  • 在该模式下,AOF 重写产生的文件将同时包含 RDB 格式的内容和 AOF 格式的内容,该文件的前半段是 RDB 格式的全量数据,而后半段是 Redis 命令格式的增量数据

当一个支持RDB-AOF混合持久化模式的Redis服务器启动并载入AOF文件时,它会检查AOF文件的开头是否包含了RDB格式的内容
请添加图片描述

原网站

版权声明
本文为[beginnerDZ]所创,转载请带上原文链接,感谢
https://blog.csdn.net/beginnerdzz/article/details/125637301