Redis持久化

官网地址

https://redis.io/docs/manual/persistence/

持化双雄

RDB（Redis DataBase）

官网介绍

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

是什么

1. 在指定的时间间隔，执行数据集的时间点快照

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

3. 这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。

能干嘛

1. 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里。

2. Redis的数据都在内存中，保存备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，一锅端。

3. Rdb保存的是dump.rdb文件。

案例演示

• 需求说明

  RDB保存到磁盘的文件叫dump.rdb。

  

• Redis6.0.16以下

  • 自动触发:在 Redis.conf 配置文件中的 SNAPSHOTTING 下配置 save 参数，来触Redis 的 RDB 持久化条件,比如"save m n":表示 m秒内数据集存在 n次修改时，自动触发 bgsave
  • save 900 1:每隔 900s(15min)，如果有超过 1 个 key 发生了变化，就写一份新的 RDB 文件save 300 10:每隔 300s(5min)，如果有超过 10 个 key 发生了变化，就写一份新的RDB 文件
  • save 60 10000:每隔 60s(1min)，如果有超过 10000 个 key 发生了变化，就写一份新的 RDB 文件

• Redis6.2以及Redis-7.0.0

操作步骤

自动触发

Redis7版本，按照redis.conf里配置的save <seconds> <changes>,修改dump.rdb文件存放路径(路径应提前创建）指定dump文件名称（默认为dump.rdb）

触发备份

恢复备份(将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。物理恢复，一定服务和备份分机隔离)

手动触发

Redis提供了两个命令来⽣成RDB⽂件，分别是save和bgsave

1. Save：在主程序中执⾏会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用。
   

2. BGSAVE(默认)：Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程。（fork：在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀）

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

优劣势

• 优势
  1. 适合大规模的数据恢复
  2. 按照业务定时备份
  3. 对数据完整性和一致性要求不高
  4. RDB 文件在内存中的加载速度要比 AOF 快得多
• 劣势
  1. 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
  2. 内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能
  3. RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑

如何检查修复dump.rdb文件

redis-check-rdb命令

redis-check-rdb /dump.rdb绝对路径

如何禁用快照

1. 动态所有停止RDB保存规则的方法：redis-cli config set save ""
2. 快照禁用

RDB优化配置项详解

配置文件SNAPSHOTTING模块

save <seconds> <changes>：快照触发条件

dbfilename：快照名称（默认dump.rdb）

dir：快照存放位置

stop-writes-on-bgsave-error：默认yes。如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求

rdbcompression：默认yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

rdbchecksum：默认yes。在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。

AOF（Append Only File）

官网介绍

是什么

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

默认情况下，redis是没有开启AOF(append only file)的。开启AOF功能需要设置配置：appendonly yes 。

能干嘛

Aof保存的是appendonly.aof文件

AOF持久化工作流程

1. Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2. 在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3. AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
4. 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
5. 当Redis Server 服务器重启的时候会从AOF文件载入数据。

AOF缓冲区三种写回策略

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

AOF配置/启动/修复/恢复

开启aof，使用默认写回策略，每秒钟；保存路径（redis6AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的 dir 配置，redis7之后最新dir + appenddirname）。

aof文件-保存名称

redis6：有且仅有一个"appendonly.aof"

Redis7.0：Multi Part AOF的设计

从1到3

1. base基本文件
2. incr增量文件
3. manifest清单文件

修复：redis-check-aof --fix

恢复：重启redis

优劣势

优势：更好的保护数据不丢失 、性能高、可做紧急恢复。

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

AOF重写机制

• 是什么

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

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

• 触发机制
  • 官网默认配置
    （注意 ，同时满足，且的关系才会触发1.根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍。2.重写时满足的文件大小）
  • 自动触发：满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
  • 手动触发：客户端向服务器发送bgrewriteaof命令。
• 重写原理
  • 在重写开始前，redis会创建一个"重写子进程"，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
  • 与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
  • 当"重写子进程"完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
  • 当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
  • 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
• 配置文件APPEND ONLY MODE模块

小总结

RDB-AOF混合持久化

官网建议

rdb vs aof（数据恢复顺序和加载流程：在同时开启rdb 和aof 持久化时，重启时只会加载 aof 文件，不会加载 rdb 文件）

同时开启两种持久化方式

开启混合方式设置：设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用

RDB+AOF的混合方式---------> 结论：RDB镜像做全量持久化，AOF做增量持久化

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写

纯缓存模式（内存服务器）

同时关闭RDB+AOF

• 禁用RDB：save ""（禁用rdb持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件）
• 禁用aof：appendonly no（禁用aof持久化模式下，我们仍然可以使用命令bgrewriteaof生成aof文件）