Redis 持久化机制

Redis 持久化机制RDB 与 AOFRedis 支持 RDB 和 AOF 两种持久化机制。持久化的作用是避免 Redis 进程退出后造成数据丢失当 Redis 下次重启时可以利用之前生成的持久化文件进行数据恢复。第四章主要围绕两部分展开一是 RDB、AOF 的配置和运行流程二是控制持久化过程的相关命令例如bgsave和bgrewriteaof。下面按照课件顺序对 Redis 持久化机制进行整理。4.1 RDBRDB 持久化是把当前 Redis 进程中的数据生成快照并保存到硬盘的过程。触发 RDB 持久化的方式分为两类手动触发和自动触发。4.1.1 触发机制手动触发主要对应两个命令save和bgsave。save命令会阻塞当前 Redis 服务器直到 RDB 持久化过程完成为止。如果 Redis 实例占用的内存比较大这个过程可能造成长时间阻塞所以实际中基本不采用这种方式。bgsave命令会让 Redis 进程执行fork操作创建子进程真正的 RDB 持久化过程由子进程负责完成后子进程自动结束。它只会在fork阶段发生阻塞一般时间很短。Redis 内部所有涉及 RDB 的操作基本都采用类似bgsave的方式。除了手动触发Redis 还支持自动触发 RDB 持久化。在实际使用中自动触发机制更有价值主要包括以下几种情况使用save配置。例如save m n表示在m秒内数据集发生了n次修改就自动触发 RDB 持久化。从节点进行全量复制时主节点会自动执行 RDB 持久化然后把 RDB 文件内容发送给从节点。执行shutdown命令关闭 Redis 时会执行 RDB 持久化。4.1.2 流程说明bgsave是主流的 RDB 持久化方式它的运行流程可以概括为以下几步。首先执行bgsave命令后Redis 父进程会判断当前是否存在其他正在执行的子进程例如 RDB 或 AOF 子进程。如果存在bgsave命令会直接返回。然后父进程执行fork创建子进程。fork过程中父进程会阻塞。可以通过info stats命令查看latest_fork_usec选项获取最近一次fork操作的耗时单位是微秒。当fork完成后bgsave命令会返回Background saving started信息。此时父进程不再被阻塞可以继续响应其他命令。接着子进程开始创建 RDB 文件。它会根据父进程的内存生成临时快照文件完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成 RDB 的时间对应info统计中的rdb_last_save_time选项。最后子进程会发送信号给父进程表示持久化完成父进程再更新相关统计信息。4.1.3 RDB 文件的处理RDB 文件的处理主要包括保存、压缩和校验三个方面。在保存方面RDB 文件会保存在dir配置指定的目录下默认目录是/var/lib/redis/。文件名由dbfilename配置指定默认是dump.rdb。Redis 运行期间也可以通过config set dir {newDir}和config set dbfilename {newFilename}动态修改保存目录和文件名下次运行时RDB 文件就会保存到新的目录中。在压缩方面Redis 默认采用 LZF 算法对生成的 RDB 文件进行压缩。压缩后的文件通常远小于内存大小。该功能默认开启也可以通过config set rdbcompression {yes|no}动态修改。虽然压缩 RDB 会消耗 CPU但它可以大幅降低文件体积方便保存到硬盘或者通过网络发送给从节点因此课件中建议开启。在校验方面如果 Redis 启动时加载到损坏的 RDB 文件会拒绝启动。这时可以使用 Redis 提供的redis-check-dump工具检测 RDB 文件并获取对应的错误报告。4.1.4 RDB 的优缺点RDB 是一个紧凑压缩的二进制文件代表 Redis 在某个时间点上的数据快照。它非常适合用于备份、全量复制等场景。例如可以每 6 小时执行一次bgsave备份并把 RDB 文件复制到远程机器或者文件系统中例如 HDFS用于灾备。Redis 加载 RDB 恢复数据的速度远远快于 AOF。不过RDB 方式没办法做到实时持久化或秒级持久化。因为bgsave每次运行都需要执行fork创建子进程这属于重量级操作频繁执行成本过高。此外RDB 文件使用特定的二进制格式保存。Redis 版本不断演进的过程中出现过多个 RDB 版本因此兼容性上可能存在风险。4.2 AOFAOF 的全称是 Append Only File。AOF 持久化会以独立日志的方式记录每次写命令Redis 重启时再重新执行 AOF 文件中的命令从而达到恢复数据的目的。AOF 的主要作用是解决数据持久化实时性的问题。目前它已经是 Redis 持久化的主流方式。理解 AOF 持久化机制有助于在数据安全性和性能之间做出平衡。4.2.1 使用 AOF开启 AOF 功能需要设置配置项appendonly yesAOF 默认不开启。AOF 文件名通过appendfilename配置设置默认是appendonly.aof。它的保存目录和 RDB 持久化方式一致都是通过dir配置指定。AOF 的工作流程包括四个步骤命令写入、文件同步、文件重写和重启加载。所有写入命令会追加到aof_buf缓冲区中。AOF 缓冲区会根据对应策略向硬盘做同步操作。随着 AOF 文件越来越大需要定期对 AOF 文件进行重写达到压缩的目的。当 Redis 服务器启动时可以加载 AOF 文件进行数据恢复。4.2.2 命令写入AOF 命令写入的内容是文本协议格式。以set hello world为例在 AOF 缓冲区中会追加如下文本*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n这里遵守 Redis 协议格式。Redis 选择文本协议课件中给出的原因主要有三个文本协议具备较好的兼容性实现简单并且具备可读性。AOF 过程中之所以需要aof_buf缓冲区是因为 Redis 使用单线程响应命令。如果每次写 AOF 文件都直接同步硬盘性能就会从内存读写变成 IO 读写必然下降。先写入缓冲区可以有效减少 IO 次数同时 Redis 还可以提供多种缓冲区同步策略让使用者根据需要做出平衡。4.2.3 文件同步Redis 提供了多种 AOF 缓冲区同步文件策略由appendfsync参数控制。可配置值说明always命令写入aof_buf后调用fsync同步完成后返回everysec命令写入aof_buf后只执行write操作不进行fsync每秒由同步线程进行fsyncno命令写入aof_buf后只执行write操作由 OS 控制fsync频率这里涉及两个系统调用write和fsync。write操作会触发延迟写机制。Linux 在内核中提供页缓冲区用来提升硬盘 IO 性能。write操作写入系统缓冲区后会立即返回真正同步到硬盘依赖系统调度机制例如缓冲区页空间写满或者达到特定时间周期。如果同步文件之前系统发生故障宕机缓冲区内的数据就会丢失。fsync针对单个文件操作会强制进行硬盘同步。fsync会一直阻塞直到数据写入硬盘。如果配置为always每次写入都要同步 AOF 文件性能很差。在一般的 SATA 硬盘上只能支持大约几百 TPS 写入。除非数据非常重要否则不建议配置。如果配置为no由于操作系统同步策略不可控虽然性能提高了但数据丢失风险也大幅增加。除非数据重要程度很低一般也不建议配置。如果配置为everysec这是默认配置也是推荐配置。它兼顾了数据安全性和性能理论上最多丢失 1 秒的数据。4.2.4 重写机制随着命令不断写入 AOF文件会越来越大。为了解决这个问题Redis 引入了 AOF 重写机制用来压缩文件体积。AOF 文件重写是把 Redis 进程内的数据转化为写命令并同步到新的 AOF 文件中。重写后的 AOF 文件之所以可以变小主要有三个原因进程内已经超时的数据不再写入文件。旧 AOF 中的无效命令例如del、hdel、srem等重写后会被删除只需要保留数据的最终版本。多条写操作可以合并为一条例如lpush list a、lpush list b、lpush list c可以合并为lpush list a b c。较小的 AOF 文件一方面可以降低硬盘空间占用另一方面也可以提升 Redis 启动时数据恢复的速度。AOF 重写过程可以手动触发也可以自动触发。手动触发是调用bgrewriteaof命令。自动触发由auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数决定。其中auto-aof-rewrite-min-size表示触发重写时 AOF 的最小文件大小默认是 64MBauto-aof-rewrite-percentage代表当前 AOF 占用大小相比上次重写时增加的比例。当触发 AOF 重写时运行流程如下。首先执行 AOF 重写请求。如果当前进程正在执行 AOF 重写请求不会执行如果当前进程正在执行bgsave操作重写命令会延迟到bgsave完成之后再执行。然后父进程执行fork创建子进程。fork之后主进程继续响应其他命令。所有修改操作会写入 AOF 缓冲区并根据appendfsync策略同步到硬盘以保证旧 AOF 文件机制正确。由于子进程只拥有fork之前的内存信息所以父进程还需要把fork之后这段时间的修改操作写入 AOF 重写缓冲区。接着子进程根据内存快照把命令合并到新的 AOF 文件中。最后子进程完成重写后会发送信号给父进程。父进程把 AOF 重写缓冲区内临时保存的命令追加到新的 AOF 文件中然后用新的 AOF 文件替换旧的 AOF 文件。4.2.5 启动时数据恢复当 Redis 启动时会根据 RDB 和 AOF 文件的内容进行数据恢复。课件中的恢复流程可以整理为启动 Redis 后先判断是否开启 AOF。如果开启 AOF则判断是否存在 AOF 文件存在时加载 AOF如果没有开启 AOF则判断是否存在 RDB 文件存在时加载 RDB。加载成功则启动成功加载失败则启动失败。4.3 本章重点回顾Redis 提供了两种持久化方案RDB 和 AOF。RDB 可以视为内存快照。它生成的内容更加紧凑占用空间较小恢复速度更快。但是生成 RDB 的开销较大不适合进行实时持久化一般用于冷备和主从复制。AOF 可以视为对修改命令的保存。Redis 恢复数据时需要重放这些命令并且 AOF 有重写机制可以定期压缩 AOF 文件。RDB 和 AOF 都会使用fork创建子进程利用 Linux 子进程拥有父进程内存快照的特点进行持久化从而尽可能不影响主进程继续处理后续命令。