0%

Redis持久化策略

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

RDB持久化

触发机制

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

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

自动触发

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

1
2
3
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后,日志中会输出下列信息

1
2
3
4
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协议格式写入缓冲区,该格式为文本格式。

1
*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要慢