Redis-持久化

发表于 更新于 分类于 ，

持久化

就是把数据写到磁盘里面。在实际的应用场景中，会存在服务器突然的宕机，数据全部打到mysql上，这个对于我们来说是灾难性的，所以我们需要让redis可以自己把数据写到服务器中

image-20240331212516033

RDB(Redis DataBase)

RDB持久性以指定的时间间隔执行数据集的时间点快照。

实现类似于照片记录效果的方式，就是把某个时刻的数据与状态以文件的形式写到了磁盘的上面，也就是快照。这样一来，即使是服务器故障宕机，快照文件也不会丢失，数据的可靠性也得到了保证。

==这个快照文件也被称为了RDB文件（dump.rdb),其中，RDB就是Redis Database的缩写==

会直接去读这个dump.rdb文件，重新写回redis的缓存里

Redis6与Redis7

在Redis7里面，把持久话RDB的保存规则发生了改变，尤其是时间记录额度的变化

vim redis7.conf,因为底层做了优化，所以不需要像之前一样记录的那么频繁了

image-20240331213643968

image-20240331213709629

自动触发

redis 默认使用

**image-20240331230827587image-20240331231302890

执行flashall/flushdb命令也会产生dump.rdb文件，但是里里面是空的，没有意义

手动触发

满足不了要求，但是希望是立马就备份，产生rdb文件，就需要开启手动的备份

redis提供了两个命令来生成RDB文件，分别是save喝bdsave

相当于在后台开启了一个子进程，可以立即的开启备份

image-20240331232230372

生产上只能用bgsave，绝对不能用save

save

在主程序中执行回阻塞当前的redis服务器，直到持久化工作完成执行save命令期间，redis是不能处理其他命令的，线上是禁止使用的

bgsave（默认）

image-20240331232606065

image-20240331232850986

image-20240331232902475

什么是fork

在Linux系统中，fork会产生一个与父进程完全向同伴的一个子进程，但是子进程会在此后多会exec系统调用，处于效率考虑，尽量的避免膨胀

lastsave

可以通过lastsave命令去获取最后一次成功执行快照的时间

image-20240331233019774

RDB 优缺点

优点

  • 适合大规模的数据恢复
  • 按照业务定时进行备份
  • 对于数据的完整性喝一致性的要求不高
  • RDB文件在内存中的加载速度要比AOF快得多

缺点

如果你需要在redis停止工作时，比如断电之后，把损失降低到最低，那么rdb并不好

RDB需要经常的fork()以便使用子进程在磁盘上持久话，如果数据集很大，fork()可能会很耗时，并且数据集很大而且CPU性能不是很好的时候，可能会导致Redis停止为客户端服务几毫秒甚至于疫苗

如何检查并修复我们的RDB文件

image-20240331234106128

如何禁用快照

image-20240331234255878

image-20240331234309380

RDB优化配置项详解snapshotting模块

image-20240331234534060

image-20240331234747105

image-20240331234813084

总结

image-20240331234853713

AOF(Append Only file)

如果宕掉了，就load 数据 写回实例里。会以日志的形式记录下每个写的操作，然后将Redis执行过的所有写指令记录下来，（读操作不记录），只允许追加文件不允许改写文件，redis在启动之初会读取该文件重新构建数据。

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

默认情况下使用的AOF，开启AOF功能需要配置appendonly yes

image-20240401095600434

三种写回策略

Always

everysec

no

image-20240401095655676 image-20240401095950257

redis6与redis7

image-20240401101931550

优点缺点

优点：更好的保护数据不被丢失，性能高，可以做紧急恢复

  • 使用AOF redis更加的持久，你可以设计不同的fsync策略（三种写回策略），即使是每秒写入，写入的性能依旧是不错的，fsync是使用后台线程执行的，当没有fsync正在进行的时候，主线程会努力的执行写入，只会丢失一秒钟的写入。
  • AOF日志是一个仅附加日志，因此不会出现寻道问题，也不会在断电的时候出现损坏的问题，即使由于某种原因，磁盘已经满了或者其他的原因日志以写一般的命令结尾，redis-check-aof也能很轻松的修复。
  • 当AOF变得太大的时候，redis能够在后台重写AOF，重写是完全安全的，因为当redis继续附加到旧文件时，会创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，redis就会切换两者并开始附加到新的那一个。
  • AOF以易于理解喝解析的格式依次包含所有操作的日志，您甚至可以轻松的导出AOF文件，如歌不小心使用了flushall命令刷新了所有的内容，只要在此期间内没有执行日志重写工作，您仍然可以通过停止服务器，删除最新命令并重新启动redis来保存数据集。

打开appendonly.aof.1.incr.aof里面一定有个flushall，把这个命令删掉

缺点

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

AOF重写机制

由于AOF持久话是redis不断将写命令记录到AOF文件中，随着redis的不断的进行，AOF的文件就会越来越大，占用的服务器内存越大，以及AOF恢复时间要求越长。

==为了解决这个问题，redis新增了重写机制，当AOF的文件的大小超过了所设定的峰值时，redis就会自动的启动AOF文件内容压缩，只保留恢复数据的最小指令集，或者手动使用命令bgrewriteaof==

峰值

image-20240401104852636 image-20240401104918329

总结

image-20240401110224729

image-20240401110249259

RDB-AOP混合持久化

可以同时共存 ， AOF说的算

image-20240401111518010

在这种情况下，redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存。

设置aof-use-rdbpreamble都值为yes，yes表示开启设置no表示禁用

RDB镜像做全量吃就话，AOF做增量持久化

image-20240401130628985

纯缓存模式