Redis ⽀持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成数据丢失问题， 当下次重启时利⽤之前持久化的⽂件即可实现数据恢复。本章内容：

• 介绍RDB、AOF的配置和运⾏流程，以及控制持久化的命令，如bgsave和bgrewriteaof
• 对常⻅持久化问题进⾏分析定位和优化。

一、RDB

        RDB持久化是把当前进程数据⽣成快照保存到硬盘的过程，触发RDB持久化过程分为⼿动触发和 ⾃动触发。

1.1、触发机制

⼿动触发分别对应save和bgsave命令：

• save命令：阻塞当前Redis服务器，直到RDB过程完成为⽌，对于内存⽐较⼤的实例造成⻓时间 阻塞，基本不采⽤。
• bgsave命令：Redis进程执⾏fork操作创建⼦进程，RDB持久化过程由⼦进程负责，完成后⾃动 结束。阻塞只发⽣在fork阶段，⼀般时间很短。

Redis 内部的所有涉及RDB的操作都采⽤类似bgsave的⽅式。

除了⼿动触发之外，Redis运⾏⾃动触发RDB持久化机制，这个触发机制才是在实战中有价值的。

1. 使⽤save配置。如"savemn"表⽰m秒内数据集发⽣了n次修改，⾃动RDB持久化。
2. 从节点进⾏全量复制操作时，主节点⾃动进⾏RDB持久化，随后将RDB⽂件内容发送给从结点。
3. 执⾏shutdown命令关闭Redis时，执⾏RDB持久化。

1.2、流程说明

bgsave 是主流的RDB持久化⽅式，下⾯根据图4-1了解它的运作流程。

图4-1 bgsave命令的运作流程

1.  执⾏bgsave命令，Redis⽗进程判断当前进是否存在其他正在执⾏的⼦进程，如RDB/AOF⼦进 程，如果存在bgsave命令直接返回。
2. ⽗进程执⾏fork创建⼦进程，fork过程中⽗进程会阻塞，通过infostats命令查看 latest_fork_usec 选项，可以获取最近⼀次fork操作的耗时，单位为微秒。
3. ⽗进程fork完成后，bgsave命令返回"Backgroundsavingstarted"信息并不再阻塞⽗进程，可 以继续响应其他命令。
4. ⼦进程创建RDB⽂件，根据⽗进程内存⽣成临时快照⽂件，完成后对原有⽂件进⾏原⼦替换。执 ⾏lastsave 命令可以获取最后⼀次⽣成RDB的时间，对应info统计的rdb_last_save_time选 项。
5. 进程发送信号给⽗进程表⽰完成，⽗进程更新统计信息。

1.3、RDB⽂件的处理

        保存：RDB⽂件保存再dir配置指定的⽬录（默认/var/lib/redis/）下，⽂件名通过dbfilename 配置（默认dump.rdb）指定。可以通过执⾏configsetdir{newDir}和configsetdbfilename {newFilename} 运⾏期间动态执⾏，当下次运⾏时RDB⽂件会保存到新⽬录。

        压缩：Redis默认采⽤LZF算法对⽣成的RDB⽂件做压缩处理，压缩后的⽂件远远⼩于内存⼤ ⼩，默认开启，可以通过参数configsetrdbcompression{yes|no}动态修改。

虽然压缩RDB会消耗CPU，但可以⼤幅降低⽂件的体积，⽅便保存到硬盘或通过⽹络发送到 从节点，因此建议开启。

        校验：如果Redis启动时加载到损坏的RDB⽂件会拒绝启动。这时可以使⽤Redis提供的redis check-dump⼯具检测RDB⽂件并获取对应的错误报告。

1.4、RDB的优缺点

• RDB是⼀个紧凑压缩的⼆进制⽂件，代表Redis在某个时间点上的数据快照。⾮常适⽤于备份，全 量复制等场景。⽐如每6⼩时执⾏bgsave备份，并把RDB⽂件复制到远程机器或者⽂件系统中 （如hdfs）⽤于灾备。
• Redis加载RDB恢复数据远远快于AOF的⽅式。
• RDB⽅式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运⾏都要执⾏fork创建⼦进 程，属于重量级操作，频繁执⾏成本过⾼。
• RDB⽂件使⽤特定⼆进制格式保存，Redis版本演进过程中有多个RDB版本，兼容性可能有⻛ 险。

二、AOF

        AOF（AppendOnlyFile）持久化：以独⽴⽇志的⽅式记录每次写命令，重启时再重新执⾏AOF ⽂件中的命令达到恢复数据的⽬的。AOF的主要作⽤是解决了数据持久化的实时性，⽬前已经是Redis 持久化的主流⽅式。理解掌握好AOF持久化机制对我们兼顾数据安全性和性能⾮常有帮助。

2.1、使⽤AOF

        开启AOF功能需要设置配置：appendonlyyes，默认不开启。AOF⽂件名通过appendfilename 配置（默认是appendonly.aof）设置。保存⽬录同RDB持久化⽅式⼀致，通过dir 配置指定。AOF的⼯作流程操作：命令写⼊（append）、⽂件同步（sync）、⽂件重写 （rewrite）、重启加载（load），如图4-2所⽰。

图4-2AOF⼯作流程

1.  所有的写⼊命令会追加到aof_buf（缓冲区）中。
2. AOF缓冲区根据对应的策略向硬盘做同步操作。
3. 随着AOF⽂件越来越⼤，需要定期对AOF⽂件进⾏重写，达到压缩的⽬的。
4. 当Redis服务器启动时，可以加载AOF⽂件进⾏数据恢复。

2.2、命令写⼊

        AOF命令写⼊的内容直接是⽂本协议格式。例如sethelloworld这条命令，在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还可以提供多种缓冲区同步策略，让⽤⼾根据⾃⼰的需求做出合理的平衡。

2.3、⽂件同步

        Redis 提供了多种AOF缓冲区同步⽂件策略，由参数appendfsync控制，不同值的含义如表4-1所⽰。

表4-1AOF缓冲区同步⽂件策略

可配置值	说明
always	命令写⼊aof_buf后调⽤fsync同步，完成后返回
everysec	命令写⼊aof_buf后只执⾏write操作，不进⾏ fsync。每秒由同步线程进⾏fsync。
no	命令写⼊aof_buf后只执⾏write操作，由OS控制 fsync 频率。

系统调⽤write和fsync说明：

• write操作会触发延迟写（delayedwrite）机制。Linux在内核提供⻚缓冲区⽤来提供硬盘IO性 能。write操作在写⼊系统缓冲区后⽴即返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区 ⻚空间写满或达到特定时间周期。同步⽂件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
• Fsync针对单个⽂件操作，做强制硬盘同步，fsync将阻塞直到数据写⼊到硬盘。
• 配置为always时，每次写⼊都要同步AOF⽂件，性能很差，在⼀般的SATA硬盘上，只能⽀持⼤ 约⼏百TPS写⼊。除⾮是⾮常重要的数据，否则不建议配置。
• 配置为no时，由于操作系统同步策略不可控，虽然提⾼了性能，但数据丢失⻛险⼤增，除⾮数据 重要程度很低，⼀般不建议配置。
• 配置为everysec，是默认配置，也是推荐配置，兼顾了数据安全性和性能。理论上最多丢失1秒的 数据。

2.4、重写机制

        随着命令不断写⼊AOF，⽂件会越来越⼤，为了解决这个问题，Redis引⼊AOF重写机制压缩⽂ 件体积。AOF⽂件重写是把Redis进程内的数据转化为写命令同步到新的AOF⽂件。 重写后的AOF为什么可以变⼩？有如下原因：

• 进程内已超时的数据不再写⼊⽂件。
• 旧的AOF中的⽆效命令，例如del、hdel、srem等重写后将会删除，只需要保留数据的最终版 本。
• 多条写操作合并为⼀条，例如lpushlista、lpushlistb、lpushlist从可以合并为lpushlistab c。

较⼩的AOF⽂件⼀⽅⾯降低了硬盘空间占⽤，⼀⽅⾯可以提升启动Redis时数据恢复的速度。

AOF重写过程可以⼿动触发和⾃动触发：

• ⼿动触发：调⽤bgrewriteaof命令。
• ⾃动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定⾃动触发时 机。
  • auto-aof-rewrite-min-size：表⽰触发重写时AOF的最⼩⽂件⼤⼩，默认为64MB。
  • auto-aof-rewrite-percentage：代表当前AOF占⽤⼤⼩相⽐较上次重写时增加的⽐例。

当触发AOF重写时，图4-3介绍它的运⾏流程。

图4-3AOF重写流程

1.  执⾏AOF重写请求。如果当前进程正在执⾏AOF重写，请求不执⾏。如果当前进程正在执⾏bgsave操作，重写命令 延迟到bgsave完成之后再执⾏。
2. ⽗进程执⾏fork创建⼦进程。
3. 重写

        a. 主进程fork之后，继续响应其他命令。所有修改操作写⼊AOF缓冲区并根据appendfsync策         略同步到硬盘，保证旧AOF⽂件机制正确。

        b. ⼦进程只有fork之前的所有内存信息，⽗进程中需要将fork之后这段时间的修改操作写⼊         AOF重写缓冲区中。

     4. ⼦进程根据内存快照，将命令合并到新的AOF⽂件中。

     5. ⼦进程完成重写

          a. 新⽂件写⼊后，⼦进程发送信号给⽗进程。

          b. ⽗进程把AOF重写缓冲区内临时保存的命令追加到新AOF⽂件中。

          c. ⽤新AOF⽂件替换⽼AOF⽂件。

2.5、启动时数据恢复

        当Redis启动时，会根据RDB和AOF⽂件的内容，进⾏数据恢复，如图4-4所⽰。

图4-4Redis根据持久化⽂件进⾏数据恢复

 

三、重点回顾

1. Redis 提供了两种持久化⽅案：RDB和AOF。
2. RDB视为内存的快照，产⽣的内容更为紧凑，占⽤空间较⼩，恢复时速度更快。但产⽣RDB的开 销较⼤，不适合进⾏实时持久化，⼀般⽤于冷备和主从复制。
3. AOF视为对修改命令保存，在恢复时需要重放命令。并且有重写机制来定期压缩AOF⽂件。
4. RDB和AOF都使⽤fork创建⼦进程，利⽤Linux⼦进程拥有⽗进程内存快照的特点进⾏持久化， 尽可能不影响主进程继续处理后续命令。