Redis实战（三）持久化

Redis Basics
15

RDB

持久化工作流程

当触发rdb持久化时，Redis主进程会fork一个子进程，该子进程的内存空间中有和主进程相同的数据，Redis子进程将数据保存为rdb文件。当Redis重启时，可以从rdb文件中加载备份的数据。

配置方式

6.0以前配置
6.0以前只能单行进行配置，这些条件之间是或的关系，只要满足其中一条就会触发rdb持久化

# save 秒数 频率 多少秒达到多少次修改就触发rdb持久化
save 1000 1
save 300 5
save 5 1000

6.0以后配置
6.0以后可以在一行配置多个条件，这些条件之间是或的关系。

save 5 1000 300 5 1000 1

rdb文件保存路径

dir /var/lib/redis

rdb文件名修改

dbfilename dump.rdb

写时复制技术 copy-on-write
因为Redis专门fork了一个子进程来进行rdb持久化，且对Redis主进程的数据进行了完全复制，这里用到了写时复制技术。

写时复制技术是操作系统系统提供的，原理是：通过fork创建来一个子进程后，并不会立即将父进程的整个内存空间完全复制一份给子进程，它通过允许父进程和子进程最初共享相同的页面来工作。这些共享页面被标记为写时复制，这意味着如果任何一个进程写入共享页面，那么就创建共享页面的副本。

触发机制

自动触发
  • 通过配置频次触发，在配置文件中，配置save项。
  • 通过一些终结命令自动触发，比如flushdb、flushall、shutdown。
手动触发
  • SAVE：会阻塞修改命令，在redis主进程进行rdb持久化
  • BGSAVE：不会阻塞，fork一个子进程进行rdb持久化
  • LASTSAVE：返回最后一次成功执行快照的时间. date -d @时间

优势

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

劣势

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

检查RDB文件是否损坏

使用redis-check-rdb rdbfile来对检查rdb文件是否损坏

哪些情况下会触发写RDB文件？

  1. 配置文件
  2. save、bgsave
  3. flushall、flushdb
  4. shutdown且没有开启aof
  5. 主从模式中，主节点自动触发

如何禁用RDB

动态设置
redis-cli config set save ''

配置文件

save ""

RDB优化配置项

在SNAPSHOTTING模块下

  • save <seconds> <changes>：设置自动触发频率
  • dbfilename：修改rdb文件名
  • dir：修改rdb文件保存路径
  • stop-writes-on-bgsave-error：是否在写rdb文件发生错误时停止
  • rdbcompression：配置rdb文件压缩等级
  • rdbchecksum：是否开启rdb文件校验和
  • rdb-del-sync-files：默认关闭

AOF

持久化工作流程

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

三种写回策略

配置项：appendfsync everysec，默认使用everysec

always ：同步写回，每次执行完命令同时将该命令写入AOF文件
优点：可靠性高，基本可以保证一致性
缺点：每次执行命令后都会执行IO操作，有性能消耗

everysec ：每秒写回一次
优点：性能适中
缺点：服务器宕机后，最多只丢失1s内的数据

no ：操作系统控制的写回，每个写命令执行完，只是先把命令写入AOF缓冲区，由操作系统决定何时将AOF缓冲区写入文件
优点：性能高
缺点：写回时机由操作系统控制，宕机后可能会丢失大量数据

AOF文件类型

7.0前aof文件仅有一个
7.0后aof有三种类型：

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

除此之外，在appenddirname文件夹下，还会有一个manifest文件，该文件是用来跟踪、管理这些AOF文件的。

也就是说，我们在appenddirname文件夹下，可用看到三个文件，分别是：

  • base：基础文件
  • incr：增量文件，可能有多个
  • manifest：清单文件

AOF文件修复

正常恢复

正常情况下，Redis重启后通过执行AOF文件中的命令来恢复数据。

异常恢复

如果Redis在写AOF文件时遇到故障，比如当写入命令执行到一半时，机器宕机，这时候AOF文件已经被破坏了。
redis-check-aof命令
当遇到上面的情况的时候，可以使用redis-check-aof --fix aoffile来对AOF文件进行修复，该工具会自动删除无法识别的部分。

优势

  1. 使用AOF Redis更加持久，且有多种写入策略可以选择，每秒fsync的写入性能仍然很棒
  2. AOF日志是一个追加日志，当写入时发生错误，redis-check-aof工具也能够轻松修复
  3. AOF日志变大时，Redis能够在后台重写AOF。
  4. AOF以易于理解和解析的格式依次包含所有操作的日志，即使在不小心执行了FLUSHALL命令后，也可以通过停止服务器，手动编辑AOF文件，删除FLUSHALL命令并重新启动Redis来恢复数据

劣势

  1. AOF文件通常比相同数据集的等效RDB文件大，恢复速度慢于RDB
  2. AOF运行效率要慢于RDB，每秒同步策略效率较好，不同步效率和RDB相同

AOF 重写机制

是什么？

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

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

也可以手动使用命令bgrewriteaof来重写。

触发机制
自动触发
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

注意，上面两项必须同时满足才会触发。

  1. 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍（Redis会自动记录上次重写后aof文件的大小）
  2. 重写时满足的文件大小
手动触发

使用命令redis-cli -a password bgrewriteaof来手动触发。

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

AOF的优化配置项

RDB+AOF混合持久化

Redis支持同时开启RDB和AOF持久化方法，当两者都开启时，Redis启动流程如下：

从上图可以看出，Redis是以AOF为主。

已经有AOF了，RDB是不是没必要了？

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

开启RDB+AOF混合模式

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

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

纯缓存模式

有时候，在一些高性能服务器上，我们只需要Redis的缓存功能，而不需要它的持久化功能，那么此时我们可以禁用RDB和AOF。

禁用RDB
在配置文件中，修改save ‘’，但是还可以通过save、bgsave来生成RDB文件。

禁用AOF
在配置文件中，修改apendonly no，但是还可以通过bgrewriteaof命令来生成AOF文件。