Redis持久化技术

一 总体介绍

二 RDB

2.1 官网介绍

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

2.2 作用

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

2.3 案例

2.3.1 配置文件

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

2.3.2 操作步骤

2.3.2.1 自动触发

1. Redis 7 版本，按照redis.conf里配置的save
2. 设定 5秒2次修改

   save 5 2
   

3. 修改dump文件保存路径
   
   修改为：

   dir /mydata/myredis/dumpfiles
   

4. 修改dump文件名称
   
   修改完成后，可通过 config get 来获取配置项。
5. 触发备份
6. 如何恢复
   • 将备份文件（dump.rdb）移动到redis按照目录并启动服务即可。
   • 执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义。
   • 不可以把备份文件dump.rdb和生成redis服务器放在同一台服务器，必须分开各自存储，以防生产物理损坏后备份文件也挂了。

2.3.2.2 手动触发

save与BGSAVE

redis提供了两个命令来生成RDB文件，分别是save和bgsave。
生成上只允许使用BGSAVE而不允许使用SAVE

• save在主程序中执行会阻塞当前redis服务器，直到持久化工作完成，执行save命令期间，Redis不能处理其他命令，线上禁止使用。
  
• BGSAVE：Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该出发方式会fork一个子进程由子进程复制持久化过程。Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。
  

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

2.4 优势

• RDB是Redis数据的一个非常进程的单文件时间点表示。RDB文件非常适合备份。例如，您可能希望在最近的24小时内每小时归档一次RDB文件，并在30天内每天保存一个RDB快照。这使您可以在发生灾难时轻松恢复不同版本的数据集。
• RDB非常适合灾难恢复，它是一个可以传输到远程数据中心或Amazon S3（可能已加密）的压缩文件。
• RDB最大限度地提高了Redis的性能，因为Redis父进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的子进程。父进程永远不会执行磁盘I/O或类似操作。
• 与AOF相比，RDB允许使用大数据集更快地恢复。
• 在副本上，RDB支持重启和故障转移后的部分重新同步。

总结：

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

2.5 RDB的缺点

• 如果您需要在Redis停止工作时（例如断电后）将数据丢失的可能性降到最低，那么RDB并不好，您可以配置生产RDB的不同保存点（例如，在对数据集至少5分钟或100次写入之后，您可以有多个保存点）。但是，您通常会每5分钟或更长时间创建一次RDB快照，因此，如果Redis由于任何原因在没有正确关闭的情况下停止工作，您应该准备好丢失最新分钟的数据。
• RDB需要经常fork()以便使用子进程在磁盘上持久化。如果数据集很大，fork()可能会很耗时，并且如果数据集很大并且CPU性能不是很好，可能会导致Redis停止为客户端服务几毫秒甚至一秒钟。AOF也需要fork()但频率较低，您可以调整要重写日志的频率，而不需要对持久性进行任何权衡。

总结：

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

2.6 如何检测修复dump.rdb文件

2.7 哪些情况下会触发RDB快照？

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

2.8 如何禁用快照呢？

• 动态停止RDB保存规则的方法：

  reids-cli config set save ""
  

• 禁用快照
  

2.9 RDB优化配置项详解

配置文件SNAPSHOTTING模块：

• save
• dbfilename
• 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

3.1 简介

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

3.2 保存文件

AOF保存的是appendonly.aof文件

3.3 AOF持久化工作流程

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

3.4 AOF缓冲区三种写回策略

3.4.1 三种写回测试

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

3.4.2 三种写回策略总结

3.5 配置实战案例

3.5.1 6 vs 7

1. 开启aof

   # 默认是no关闭，设置为yes就打开aof持久化支持
   appendonly no   
   

2. 使用默认写回策略，每秒钟
   

3. aof文件-保存路径

   • redis6：AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置。
   • redis7：dir + appenddirname
     

4. aof文件-保存名称

   • redis6：有且仅有一个

   • redis 7 : Redis 7.0 Multi Part AOF的设计，有3个文件。
     

     MP-AOF实现
     概述：顾明思义，MP-AOF就是将原来的单个AOF文件拆分成多个AOF文件。在MP-AOF中，我们将AOF分为三种类型，分别为：

     • BASE：表示基础AOF，它一般由子进程通过重写产生，该文件最多只有一个。
     • INCR：表示增量AOF，它一般会在AOFRW开始执行时被创建，该文件可能存在多个。
     • HISTORY：表示历史AOF，它由BASE和INCR AOF变化而来，每次AOFRW成功完成时，本次AOFRW之前对应的BASE和INCR AOF都将变为HISTORY，HISTORY类型的AOF会被Redis自动删除。

     为了管理这些AOF文件，我们引入了一个manifest（清单）文件来跟踪、管理这些AOF。同时，为了便于AOF备份和拷贝，我们将所有的AOF文件和manifest文件放入一个单独的文件目录中，目录名由appenddirname配置（Redis7.0新增配置项）决定。

3.5.2 Redis7.0 config 配置项

AOF修复命令：

redis-check-aof --fix appendonly.aof.1.incr.aof

3.5 优势

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

3.6 劣势

1. AOF文件通常比相同数据集的等效RDB文件大。
2. 根据确切的fsync策略，AOF可能比RDB慢。一般来说，将fsync设置为每秒性能仍然非常高，并且在禁用fsync的情况下，即使在高负载下它也应该与RDB一样快。即使在巨大的写入负载的情况下，RDB仍然能够提供按关于最大延迟的更多保证。

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

3.7 AOF重写机制

3.7.1 什么是AOF重写机制

由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis不断的运行，AOF的文件会越来越大，文件越大，占用服务器内存越大以及AOF恢复要求时间越长。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过了所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。或者可以手动使用命令bgrewriteaof来重写。

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

3.7.2 触发机制

注意：同时满足，且的关系才会触发

1. 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍。
2. 重写时满足的文件大小

3.7.2.1 自动触发

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

3.7.2.2 手动触发

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

3.7.2.3 总结

AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
AOF文件重写触发机制：通过redis.conf配置文件中的auto-aof-rewrite-percentage：默认值为100，以及auto-aof-rewriet-min-size：64mb配置。也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

3.7.3 重写原理

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

3.8 AOF优化配置项详解

配置文件APPEND ONLY MODE：

四 RDB-AOF混合持久化

4.1 rdb vs aof

两者是可以共存的，并且以AOF为准。

数据恢复顺序和加载流程：

4.2 怎么选，用哪个？

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

4.3 同时开启两种持久化方式如何？

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

4.4 推荐方式

**RDB+AOF混合方式：**结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

1. 开启混合方式设置：设置aof-use-rdb-preamble的值为yes，yes表示开启，设置为no表示禁用。
2. RDB+AOF的混合方式：RDB镜像做全量持久化，AOF做增量持久化。先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。

五 纯缓存模式（同时关闭RDB+AOF）

#禁用rdb
#禁用rdb持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件。
save ""

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