Redis持久化【学习笔记】

Redis持久化

官网地址: https://redis.io/docs/manual/persistence/

在这里插入图片描述

一.Reids RDB(Redis DataBase)

官网介绍:RDB(Redis 数据库):RDB 持久性以指定的时间间隔执行数据集的时间点快照。

1.是什么

在指定的时间间隔,执行数据集的时间点快照
实现类似照片记录效果的方式,就是把某一时刻的数据和状态以文件的形式写道磁盘上,也就是快照,这样一来即使故障宕机,快照文件也不会丢失,数据的可靠性也就得到了保证。
这个快照文件就称为RDB文件(dump.rdb),其中,RDB就是Redis DataBase的缩写

2.能干嘛

1.在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot内存快照,它恢复时再将磁盘快照文件直接读回到内存里
2.Redis的数据都在内存中,保持备份时它执行的是全量快照,也就是说,把内存中的所有数据都记录到磁盘中,一锅端
3.Rdb保存的是dump.rdb文件

3.案例演示

1.需求说明:
在这里插入图片描述
2.配置文件(6 VS 7)
Redis6.0.16以下
在这里插入图片描述
Redis6.2以及Redis-7.0.0
在这里插入图片描述
操作步骤:
1.自动触发

  • Rdis7版本,按照redis.conf里配置save在这里插入图片描述

  • 本次案例5秒2次修改在这里插入图片描述

  • 修改dump文件保存路径在这里插入图片描述

  • 修改dump文件名称在这里插入图片描述

  • 触发备份
    第一种情况:在这里插入图片描述第二种情况:在这里插入图片描述

  • 如何恢复
    1.将备份文件(dump.rdb)移动到redis安装目录并启动服务即可
    2.备份成功后故意用flushdb情况redis,看看是否可以恢复数据
    3.结论:执行flushall/flushdb命令也会产生dump.rdb文件,但里面是空的,无意义
    在这里插入图片描述

  • 物理恢复,一定服务和备份分机隔离在这里插入图片描述
    2.手动触发

save和bgsave

  • Redis提供了两个命令来生成RDB文件,分别是save和bgsave
    在这里插入图片描述
  • Save

在主程序中执行会阻塞当前redis服务器,直到持久化工作完成
执行save命令期间,Redis不能处理其他命令,线上禁止使用
案例
在这里插入图片描述

  • BGSAVE(默认)

Redis会在后台异步进行快照操作,不阻塞
快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程
Redis会使用bgsave对当前内存中的所有数据做快照,这个操作是子进程在后台完成的,这就允许主进程同时可以修改数据

fork是什么
在Linux程序中,fork()会产生一个和父进程完全相同的子进程,但子进程在此后多会exec系统调用,出于效率考虑,尽量避免膨胀

案例
在这里插入图片描述

LASTSAVE
可以通过lastsave命令获取最后一次成功执行快照的时间
案例:
在这里插入图片描述

4.优势

小总结:

  1. 适合大规模的数据恢复
  2. 按照业务定时备份
  3. 对数据完整性和一致性要求不高
  4. RDB文件在内存中的加载速度要比AOF快的多

5.劣势

小总结:

在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失从当前至最近一次快照期间的数据,快照之间的数据会丢失
内存数据的全量同步,如果数据量太大会导致I/O严重影响服务器性能
RDB依赖于主进程的fork,在更大的数据集中,这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份,大致2倍的膨胀性,需要考虑

数据丢失案例

正常录入数据在这里插入图片描述
kill -9 故意模拟意外宕机
在这里插入图片描述
redis重启恢复,查看数据是否丢失在这里插入图片描述

6.如何检查修复dump.rdb文件

在这里插入图片描述

7.哪些情况会触发RDB快照

配置文件中默认的快照配置
手动save/bgsave命令
执行flushall/flushdb命令也会产生dump.rdb文件,但里面是空的,无意义
执行shutdown且没有设置开启AOF持久化
主从复制时,主节点会自动触发

8.如何禁用快照

动态所有停止RDB保存规则的方法: redis-cli config set save “”
快照禁止:
在这里插入图片描述

9.RDB优化配置项详解

配置文件SNAPSHOTTING模块

  • save
  • dbfilename
  • dir
  • stop-writes-on-bgsave-error在这里插入图片描述
  • rdbcompression
    在这里插入图片描述
  • rdbchecksum在这里插入图片描述
  • rdb-del-sync-files
    在这里插入图片描述

10.小总结

在这里插入图片描述

二.AOF(Append Only File)

1.是什么

以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认情况下,redis是没有开启AOF(append only file)的。开启AOF功能需要设置配置:appendonly yes

2.能干嘛

在这里插入图片描述

3.AOF保存的是appendonly.aof文件

4. AOF持久化工作流程

在这里插入图片描述

5.AOF缓冲区三种写回策略

三种写回策略

  1. Always 同步写回,每个写命令执行完立刻同步将日志写回磁盘
  2. everysec 每秒写回,每个写命令执行完,只是先把日志写到AOF文件的内存缓存区,每隔1秒把缓冲区中的内容写到磁盘
  3. no 操作系统控制的写回,每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回数据

三种写回策略小总结update
在这里插入图片描述

6.案例演示和说明AOF配置/启动/修复/恢复

1. 配置文件说明

  1. 如何开启aof
    在这里插入图片描述
  2. 使用默认写回策略,每秒钟
    在这里插入图片描述
  3. aof文件-保存路径

redis6 AOF保存文件的位置和RDB保存文件的位置一样
都是通过redis.conf配置文件的dir配置在这里插入图片描述

redis7之后最新
最终路径在这里插入图片描述

  1. AOF文件-保存名称

redis6
有且仅有一个在这里插入图片描述

Redis7.0 Multi Part AOF的设计
base基本文件
incr增量文件
manifest清单文件 在这里插入图片描述

Redis 7.0config 中对应的配置项
在这里插入图片描述

2.正常恢复:

启动:设置YES 修改默认的appendonly no 改为yes
写操作继续,生成aof文件到指定的目录
在这里插入图片描述

恢复1:重启redis然后重新加载,结果OK

恢复2:
写入数据进redis,然后flushdb+shutdown服务器
新生成了dump和aof
备份新生成的aof.bak,然后删除dump/aof再看恢复
在这里插入图片描述

重启redis然后重新加载试试???
在这里插入图片描述

停止服务器,拿出我们的备份修改后再重新启动服务器看看
在这里插入图片描述

3.异常恢复

故意乱写正常的AOF文件,模拟网络闪断文件写error
在这里插入图片描述

重启Redis之后就会进行AOF文件的载入,发现启动都不行
在这里插入图片描述

异常修复命令: redis-check-aof --fix 进行修复
在这里插入图片描述

重新OK在这里插入图片描述

7.优势

更好的保护数据不丢失,性能高,可做紧急恢复

8.劣势

相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
aof运行效率要慢于rdb,每秒同步策略效率较高,不同步效率和rdb相同

9.AOF重写机制

1.是什么

启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集

2.触发机制

在这里插入图片描述

  • 自动触发

满足配置文件钟的选项后,Redis会记录上次重写时的AOF大小,
默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件要大于64M时

  • 手动触发

客户端向服务器发送bgrewriteaof命令

3.案例说明

需求说明:

启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。
举例子:比如有个key
一开始你 set k1 v1
然后改成 set k1 v2
最后改成 set k1 v3
如果不重写,那么这3条语句都在aof文件中,内容占空间不说启动的时候都要执行一遍,共计3条命令;
但是,我们实际效果只需要set k1 v3这一条,所以,
开启重写后,只需要保存set k1 v3就可以了只需要保留最后一次修改值,相当于给aof文件瘦身减肥,性能更好。
AOF重写不仅降低了文件的占用空间,同时更小的AOF也可以更快地被Redis加载。

需求验证:

启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集

步骤:

  • 前期配置准备:

开启aof
在这里插入图片描述
重写峰值修改为1k
在这里插入图片描述
关闭混合,设置为no
在这里插入图片描述
删除之前的全部aof和rdb,清除干扰项

  • 自动触发案例01

完成上述正确配置,重启redis服务器,执行set k1 v1 查看aof文件是否正常
在这里插入图片描述

查看三大配置文件
在这里插入图片描述

k1不停11111111暴涨
在这里插入图片描述

重写触发
在这里插入图片描述

  • 手动触发案例02

客户端向服务器发送bgrewriteaof命令
在这里插入图片描述

结论:在这里插入图片描述

4.重写原理

1:在重写开始前,redis会创建一个“重写子进程”,这个子进程会读取现有的AOF文件,并将其包含的指令进行分析压缩并写入到一个临时文件中。
2:与此同时,主进程会将新接收到的写指令一边累积到内存缓冲区中,一边继续写入到原有的AOF文件中,这样做是保证原有的AOF文件的可用性,避免在重写过程中出现意外。
3:当“重写子进程”完成重写工作后,它会给父进程发一个信号,父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4:当追加结束后,redis就会用新AOF文件来代替旧AOF文件,之后再有新的写指令,就都会追加到新的AOF文件中
5:重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似

10.AOF优化配置项详解

配置文件APPEND ONLY MODE模块
在这里插入图片描述

11. 小总结

在这里插入图片描述

三.RDB-AOF混合持久化

1.rdb and aof

在这里插入图片描述

2.你怎么选?用哪个?

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重写执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾

3.同时开启两种持久化方式

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始数据,因为在通常情况下AOF文件保存的数据要比RDB文件保存的数据集要完整
RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要只使用AOF呢?作者建议不要,应为RDB更适用于备份数据库(AOF在不断变化不好备份),留着rdb作为一个万一的手段

4.推荐方式

RDB+AOF混合方式
在这里插入图片描述

纯缓存模式

同时关闭RDB+AOF

save “”
禁用rdb
禁用rdb持久化模式下,我们仍然可以使用命令save,bgsave生成redb文件

appendonly no
禁用aof
禁用aof持久化模式下,我们仍然可以使用命令bgrewriteaof生成aof文件

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
以下是一些关于 Redis 持久化的可能面试问题: 1. Redis持久化有哪些方式? Redis持久化有两种方式,一种是 RDB 持久化,一种是 AOF 持久化。 2. RDB 持久化和 AOF 持久化有什么区别? RDB 持久化是将 Redis 在内存中的数据快照保存到磁盘上,而 AOF 持久化则是将 Redis 执行的每条写命令记录到磁盘上。RDB 持久化可以节约磁盘空间,但可能会丢失最近的一些数据,而 AOF 持久化可以保证数据不会丢失,但可能会占用更多的磁盘空间和写入时间。 3. Redis持久化机制是如何保证数据一致性的? Redis持久化机制可以通过在每次写操作后立即同步到磁盘,或者设置定期同步时间来保证数据一致性。 4. Redis持久化可以在运行时进行吗? 可以,Redis持久化可以在运行时进行配置和切换,例如可以在运行时从 RDB 切换到 AOF 持久化,或者从 AOF 切换到 RDB 持久化。 5. Redis持久化会对性能产生影响吗? 会,Redis持久化会增加磁盘 I/O 开销,可能会对写入性能产生一定的影响,但可以通过合理的配置来平衡性能和数据一致性。 6. Redis持久化可以与 Redis 集群一起使用吗? 可以,Redis持久化可以与 Redis 集群一起使用,但需要注意配置文件的设置和数据同步的策略。 总之,Redis持久化是保证数据一致性和可靠性的重要手段,需要根据具体的业务需求和性能要求来选择合适的持久化方式,并进行合理的配置和优化。在面试中,还需要了解 Redis 持久化的原理、机制、优缺点、与集群的结合等方面的知识。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值