Redis支持RDB和AOF两种持久化机制，持久化能够避免因进程退出而造成的数据丢失，在进程下一次启动时自动加载持久化文件中的数据。持久化通常用于备份恢复的场景，利用持久化文件进行数据迁移。

RDB持久化

触发机制

RDB持久化是把当前实例数据生成快照并保存到磁盘的过程，触发持久化可以通过手动触发或者参数自动触发。生成的RDB文件存放在DIR参数配置的目录下，文件名通过dbfilename指定，可通过config set dir {newdir}和config set dbfilename {newname}在线修改，下次持久化时会保存到新目录中。

Redis采用LZF算法对生成的RDB文件做压缩，压缩后的大小远远小于内存大小，默认开启，可以通过参数rdbcompression控制。

自动触发

Redis自动触发由参数save控制，默认格式如下

save 900 1
save 300 10
save 60 10000

在满足下列条件之一的情况会自动触发RDB持久化，输出RDB文件

  • 900秒内至少发生1次修改
  • 300秒内至少发生10次修改
  • 60秒内至少发生10000次修改

在以下场景下也会自动触发RDB持久化

  • 从节点执行全量复制时，主节点自动执行bgsave生成RDB文件并发送给从节点
  • 执行debug reload命令重新加载redis时，自动触发持久化
  • 默认情况下执行shutdown关闭实例进程时，如果没有开启AOF持久化则自动执行bgsave

手动触发

手动触发对应save和bgsave两个命令，不同之处在于save会阻塞进程直到RDB持久化完成；而bgsave会fork一个子进程专门负责持久化任务，完成后自动结束，阻塞只发生在fork阶段，通常时间会比较短。在执行bgsave后，日志中会输出下列信息

Backgroud saving started by pid 2373
DB saved on disk
RDB: 0MB of memory used by copy-on-write
Backgroud saving terminated with success

触发流程

  1. 执行bgsave命令，redis进程判断当前是否有正在执行的子进程，如果存在则直接返回
  2. redis进程fork一个子进程，fork操作过程中会阻塞redis，通过info stats查看latest_fork_usec选项可以查看最近一次fork操作耗时，单位为微妙，通常时间很短。
  3. fork完成后，返回Backgroud saving started信息并且也不在阻塞redis进程
  4. 子进程创建RDB文件，根据redis进程内存生成临时快照文件，完成后对原有文件进行替换。执行lastsave命令可以查询最后一次生成RDB文件的时间
  5. 进程发送信号给redis进程表示完成，父进程更新统计信息，子进程退出

RDB优缺点

优点：

  • RDB是一个紧凑压缩的二进制文件，其内容是Redis在某个时间点上的数据快照。通常适合用于备份、全量复制等场景
  • Redis加载RDB恢复数据远远快于AOF的方式

缺点：

  • RDB无法做到实时持久化，频繁执行bgsave去fork子进程持久化成本过高
  • RDB采用特定二进制格式保存， 会存在RDB在redis版本之间无法兼容的问题

AOF持久化

AOF持久化以独立日志记录的方式记录每次写命令，重启时再重新执行AOF文件中的命令来恢复数据，能够增量实时的进行持久化。

开启AOF功能需要设置参数appendonly为yes，默认是不开启的。文件名由appendfilename配置，默认为appendonly.aof。AOF的工作流程大致分为4步：

  1. 命令写入：所有的写入命令会追加到aof_buf缓冲区
  2. 文件同步：AOF缓冲区根据策略向磁盘做同步操作
  3. 文件重写：随着AOF文件越来越大，需要定期对AOF文件进行重写达到压缩的目的
  4. 重启加载：当Redis重启时，加载AOF文件进行重写

命令写入

AOF命令写入的内容是以Redis协议格式写入缓冲区，该格式为文本格式。

*3\r\n$3\r\nset\\r\n$5\r\nhello\r\n$5\r\nworld\r\n

文本具有很好的兼容性，并且具有可读性和可写性。

文件同步

Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制

值 含义
always 命令写入aof_buf后调用系统fsync操作同步到AOF文件中，fsync完成后线程返回
everysec 命令写入aof_buf后调用系统write操作，write操作完成后线程返回。fsync同步文件操作由专门的线程每秒调用一次
no 命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步。同步磁盘操作由操作系统负责，通常同步周期最长30秒
  • 配置为always时，每次写入都要同步AOF文件，不建议开启
  • 配置为no，由于系统同步周期不可控，并且加大了每次同步的数据量，数据安全性无法保证
  • 配置为everysec是建议的同步策略，也是默认配置。综合了性能与安全的考虑
  • write操作会触发延迟写机制。linux在内核提供页缓冲区用来提高磁盘的IO性能。write操作在写入系统缓冲区后直接返回，同步硬盘操作依赖于系统调度机制
  • fsync针对单个文件做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回

重写机制

随着命令不断的写入，AOF文件会越来越大，因此引入重写机制来压缩文件体积。AOF重写是把Redis进程内的数据转化为写命令同步到新的AOF文件。

  • 进程内已经超时的数据不再写入文件
  • AOF中含有无效命令，直接从进程中读取最新的数据
  • 多条写命令可以合并为一个

在文件体积减小的同时，也使得AOF文件能更快的被加载。

AOF重写可以手动触发和自动触发

  • 手动触发：
    直接调用bgrewriteaof命令
  • 自动触发：
    根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数控制。前者表示AOF重写时文件的最小体积，默认为64MB；后者表示当前AOF文件空间(aof_current_size)和上一次重写后AOF文件空间(aof_base_size)的比值。
    自动触发时机=aof_current_size > auto-aof-rewrite-min-size && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage。其中current_size和base_size可以在info persistence中查询

工作流程

  1. 执行AOF重写请求，如果当前正在执行bgsave则重写命令延迟到bgsave之后
  2. Redis执行fork创建子进程
  3. 由于采用写时复制技术，子进程只能共享fork操作时的内存数据
  4. 子进程根据内存快照命令合并规则写入新的AOF文件。每次批量写入的数据量由参数aof-rewrite-incrmental-fsync控制，默认32MB
  5. 新AOF文件写入完成后，子进程通知Redis更新统计信息，并将AOF缓冲区的数据写入新的AOF文件，使用新AOF文件替换旧的

重启加载

AOF持久化开启并存在AOF文件时，优先加载AOF文件，否则加载RDB文件

当AOF文件损坏时加载会失败，可以先备份一份AOF文件，并通过redis-check-aof –fix进行修复，并用diff -u比对数据的差异，找出丢失的数据

AOF优缺点

优点：

  • AOF可以实时持久化
  • AOF持久化如果因断电等情况异常关闭，最多丢失2秒的数据
  • AOF为文本可是，易于理解和解析

缺点：

  • AOF文件通常要比RDB文件大
  • AOF加载比RDB要慢