Redis 持久化详解

前言

Redis 持久化方式

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。

AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下，当 Redis 重启时，它会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

甚至可以关闭持久化功能，让数据只在服务器运行时存在。

RDB 持久化

        RDB 是默认的持久化方式，类似于 Mysql Dump，这种方式是根据配置的规则定时将内存中数据以快照的方式写入到二进制文件（全量生成一份副本存储到硬盘上，若配置压缩，Redis 会使用 LZF 算法进行压缩，提升主从复制效率），默认的文件名 dump.rdb，可以通过配置设置自动做快照持久化的方式。

 

RDB 触发机制

save 命令

        save 命令是在 Redis 进程中执行的，由于 Redis 是单线程实现，当 save 命令在执行时会阻塞 Redis 服务器一直到该命令执行完成为止，而且该命令会替换旧的 RDB 文件。当数据库数据较多时，应该避免使用该命令。

        save 命令的底层函数是 rdbSave（函数内部通过调用 rdbSaveRio 函数来完成真正的转存操作），其将 Redis 数据库 db 保存到磁盘中，如果操作成功函数返回 REDIS_OK，如果操作失败函数返回 REDIS_ERR。

        save 命令复杂度：O(N)。

 

bgsave 命令

        bgsave 命令会先使用 Redis 的 fork 函数复制一份当前进程（父进程）的副本（子进程），父进程继续处理来自客户端的请求，子进程开始将内存中的数据写入硬盘中的临时文件，当子进程写完所有的数据后，用该临时文件替换旧的 RDB 文件。由于在子进程中执行 IO 操作，所以 bgsave命令不会阻塞 Redis 服务器进程，Redis 服务器进程在此期间可以继续对外提供服务，但当使用 fork 函数时依然会阻塞 Redis 进程，虽然大部分时候使用 fork 函数是极快的，但极端下仍然出现阻塞现象。

        bgsave 命令的底层函数是 rdbSaveBackground，为了提高性能，Redis 服务器在 bgsave 命令执行期间会拒绝执行新到来的其它 bgsave 命令。

        如果想知道快照操作是否已经完成，可以使用 

lastsave 命令返回最近一次成功执行快照的时间，返回结果是一个 Unix 时间戳。

        bgsave 命令复杂度：O(N)。

        注意：在执行 fork 时操作系统（类 Unix 操作系统）会使用写时复制

（copy-on-write）策略，即 fork 函数发生的一刻，父进程和子进程共享同一块内存数据，当父进程需要修改其中的某片数据（如执行写命令）时，操作系统会将该片数据复制一份以保证子进程不受影响，所以 RDB 文件存储的是执行 fork 操作那一刻的内存数据。所以 RDB 方式理论上是会存在丢数据的情况的（fork 之后修改的的那些没有写进 RDB 文件）。

** **

save 和 bgsave 命令比较

RDB 配置

** **

RDB 触发场景

根据配置规则进行自动快照。

执行 flushall 命令：当执行 flushall 命令时，Redis 会清除数据库中的所有数据。需要注意的是：不论清空数据库的过程是否触发了自动快照的条件，只要自动快照条件不为空，Redis 就会执行一次 RDB 存储，当没有定义自动快照条件时，执行 flushall 命令不会进行 RDB 存储。

执行 save/bgsave 命令。

执行复制（replication）：当设置了主从模式时，Redis 会在复制初始化是进行自动快照，若关闭 RDB 存储模式，也会在初始主从复制时进行一次 RDB 存储。

debug reload 命令：提供 debug 级别的重启，不清空内存的一种重启。save 当前的 RDB 文件，并清空当前数据库，重新加载 RDB，加载与启动时加载类似，加载过程中只能服务部分只读请求（比如 info、ping 等），这种方式也会触发 RDB 文件的生成。

shutdown 命令：会触发 RDB 文件的生成。

** **

RDB 优点

RDB 是一个非常紧凑（compact）的文件，保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。

RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 缺点

如果需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 就可能会丢失好几分钟的数据。

每次保存 RDB 的时候，Redis 都要 fork 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

RDB 优点

建议关闭 RDB，无论是 Redis 主节点，还是从节点，都建议关掉 RDB。但是关掉不是绝对的，主从复制时还是会借助 RDB。

用作数据备份，RDB 虽然是很重的操作，但是对数据备份很有作用。文件大小比较小，可以按天或按小时进行数据备份。

主从，从开？在极个别的场景下，需要在从节点开 RDB，可以再本地保存这样子的一个历史的 RDB 文件。虽然从节点不进行读写，但是 Redis 往往单机多部署，由于 RDB 是个很重的操作，所以还是会对 CPU、硬盘和内存造成一定影响。根据实际需求进行设定。

AOF 持久化

        AOF 是 Append Only File 的缩写，比 RDB 存储方式有更好的持久化性，它将 Redis 每一个收到的写命令都通过 write 函数追加到文件中（默认是 appendonly.aof），类似于 log（记日志）的过程。当 Redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

 

AOF 触发机制

        Redis 提供了 bgrewriteaof 命令来重写 AOF 文件。

 

AOF 配置

 

AOF 文件格式

    AOF 文件中的内容完全是以纯文本格式的形式存放。

AOF 执行策略

        AOF 持久化功能的实现可以分为 命令传播，缓存追加，文件写入和保存 三个步骤。

        命令传播：当一个 Redis 客户端需要执行命令时，它通过网络连接，将协议文本发送给 Redis 服务器。

        缓存追加：当 AOF 持久化功能处于打开状态时，服务器接受命令、命令的参数、以及参数的个数、所使用的数据库等信息，将命令还原成 Redis 网络通讯协议，将协议文本追加到 AOF_BUF 末尾。

        AOF 文件的写入和保存：Redis 服务器进程是一个事件循环，这个循环中的文件事件负责处理客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行像 serverCron 函数这样需要定时运行的函数。因为服务器在处理文件事件时可能会执行写命令，使得一些内容被追加到 AOF_BUF 缓冲区的里面，所以在服务器每次结束一个事件循环之前，都会调用 flushAppendOnlyFile 函数，考虑是否需要将 AOF_BUF 缓冲区中的内容写入和保存到 AOF 文件里面。flushAppendOnlyFile 函数的行为由服务器配置的 appendfsync 的值来决定，主要包括三个配置（默认配置为 AOF_FSYNC_EVERYSEC）：

        AOF_FSYNC_ALWAYS：命令写入 AOF_BUF 后调用系统 fsync操作同步到 AOF 文件，fsync 完成后线程返回。

        AOF_FSYNC_EVERYSEC：命令写入 AOF_BUF 后调用系统 write 操作，write 完成后线程返回。fsync 同步文件操作由专门线程每秒调用一次。

        AOF_FSYNC_NO：命令写入 AOF_BUF 后调用系统 write 操作，不对 AOF 文件做 fsync 保存，保存硬盘操作由操作系统负责，通常同步周期最长 30 s。

 

写入和保存的区别

        write，会触发延迟写（delayed write）机制，Linux 在内核提供页缓冲区用来提高硬盘 IO 性能，write 操作在写入系统缓冲区后直接返回，同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。

        save，根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。fsync 针对单个文件操作（比如 AOF 文件），做强制硬盘同步，fsync 将阻塞直到写入硬盘完成后返回，保证了数据持久化。

** **

AOF 执行策略对性能和安全的影响

对于三种 AOF 保存模式，对 Redis 服务器主进程的阻塞情况如下

        AOF_FSYNC_NO，写入和保存都由主进程执行，两个操作都会阻塞主进程。保存操作只会在 AOF 关闭或 Redis 关闭时执行，或者由操作系统触发，在一般情况下，这种策略只需要为写入阻塞，因此它的写入性能很高，当然，这种性能的提高是以降低安全性为代价的：在这种策略下，如果运行的中途发生停机，那么丢失数据的数量由操作系统的缓存冲洗策略决定。

        AOF_FSYNC_EVERYSEC，写入操作由主进程执行，阻塞主进程。保存操作由子线程执行，不直接阻塞主进程，但保存操作完成的快慢会影响写入操作的阻塞时长。在通常情况下，最多丢失不多于 2 秒的数据，是一种兼顾性能和安全性的保存方案。             

        AOF_FSYNC_ALWAYS，写入和保存都由主进程执行，两个操作都会阻塞主进程。这种策略的安全性是最高的，但性能也是最差的，因为服务器必须阻塞直到命令信息被写入并保存到磁盘之后，才能继续处理请求。

        因为阻塞操作会让 Redis 主进程无法持续处理请求，所以一般说来，阻塞操作执行得越少、完成得越快，Redis 的性能就越好。

 

AOF 文件的载入和还原

创建一个不带网络连接的伪客户端（fake client）。

读取 AOF 所保存的文本，并根据内容还原出命令、命令的参数以及命令的个数。

根据命令、命令的参数和命令的个数，使用伪客户端执行该命令。

AOF 文件中的所有命令执行完毕（Redis 的命令只能在客户端的上下文中被执行，而 AOF 还原时所使用的命令来自于 AOF 文件，而不是网络，所以程序使用了一个没有网络连接的伪客户端来执行命令。伪客户端执行命令的效果，和带网络连接的客户端执行命令的效果完全一样）。

 

AOF 重写

        AOF 文件通过同步 Redis 服务器所执行的命令，从而实现了数据库状态的记录，但是，随着运行时间的流逝，AOF 文件会变得越来越大，而且，有些被频繁操作的键，对它们所调用的命令可能有成百上千、甚至上万条，AOF 文件的体积就会急速膨胀，对 Redis、甚至整个系统的造成影响。

        Redis 重写（rewrite）就是把过期的、没用的、重复的以及可优化的命令，进行化简，从而减少磁盘占用量，加快数据恢复速度。重写创建一个新的 AOF 文件来代替原有的 AOF 文件，新 AOF 文件和原有 AOF 文件保存的数据库状态完全一样，但新 AOF 文件不会包含任何浪费空间的冗余命令，所以新 AOF 文件的体积通常比旧 AOF 文件的体积要小得多。

** **

AOF 重写流程

        Redis fork 一个子进程，子进程基于当前内存中的数据，构建日志，开始往一个新的临时的 AOF 文件中写入日志，Redis 主进程，接收到客户端新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的 AOF 文件，子进程写完新的日志文件之后，Redis 主进程将内存中的新日志再次追加到新的 AOF 文件中，用新的日志文件替换掉旧的日志文件。

 

AOF 重写方式

bgrewriteaof 命令

        Redis 客户端发送 bgrewriteaof 命令，Redis 服务端 fork 一个子进程去完成 AOF 重写，将 Redis 内存中的数据进行一次回溯，回溯成 AOF 文件，并非重写 AOF 文件生成新的 AOF 文件去替换。

 

AOF 重写配置

        auto-aof-rewrite-min-size，AOF文件重写需要的尺寸

        auto-aof-rewrite-percentage，AOF文件增长率

        aof_current_size 和 aof_base_size，分别用来统计 

AOF 当前尺寸（单位：字节）和 AOF 上次启动和重写的尺寸（单位：字节）。

 

AOF 自动重写的触发时机（同时满足）

没有 bgsave 命令在进行

没有 bgrewriteaof 命令在进行

aof_current_size auto-aof-rewrite-min-size（默认值为 1 MB）

aof_current_size - aof_base_size / aof_base_size auto-aof-rewrite-percentage

** **

AOF 优点

使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。

AOF 文件是一个只进行追加操作的日志文件（append only log），因此对 AOF 文件的写入不需要进行 seek，即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等），redis-check-aof 工具也可以轻易地修复这种问题。

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。导出（export） AOF 文件也非常简单：举个例子，如果你不小心执行了 flushall 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 flushall 命令，并重启 Redis，就可以将数据集恢复到 flushall 执行之前的状态。

 

AOF 缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

AOF 在过去曾经发生过这样的 bug：因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。（举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug）测试套件里为这种情况添加了测试：它们会自动生成随机的、复杂的数据集，并通过重新载入这些数据来确保一切正常。虽然这种 bug 在 AOF 文件中并不常见，但是对比来说，RDB 几乎是不可能出现这种 bug 的。

 

AOF 优化

建议开启 AOF，如果 Redis 数据只是用作数据源的缓存，并且缓存丢失后从数据源重新加载不会对数据源造成太大压力，这种情况下，AOF 可以关。

 AOF 重写集中管理， 单机多部署情况下，发生大量 fork 可能会内存爆满。

使用 AOF_FSYNC_EVERYSEC 执行策略， 建议采用每秒刷盘策略，生产环境一般都这么配置，性能很高，QPS 还是可以上万的（QPS指每秒钟请求次数）。

RDB 和 AOF 比较

        如果 RDB 在执行 snapshotting 操作，那么 Redis 不会执行 AOF rewrite。如果 Redis 再执行 AOF rewrite，那么就不会执行 RDB snapshotting。

        如果 RDB 在执行 snapshotting，此时用户执行 

bgrewriteaof 命令，那么等 RDB 快照生成之后，才会去执行 AOF rewrite。

        同时有 RDB snapshot 文件和 AOF 日志文件，那么 Redis 重启的时候，会优先使用 AOF 进行数据恢复，因为其中的日志更完整。

开发运维常见问题

优化 fork 操作

        fork 是一个同步操作，执行 bgsave 和 bgrewriteaof 时都会执行 fork 操作。

优先使用物理机或者其他能高效支持form操作的虚拟化技术；

控制 Redis 实例最大可用内存 maxmemary。fork 操作只是执行内存页的拷贝，大部分情况速度是比较快的。Redis 内存越大，内存页越大，可以使用 maxmemary 规划 Redis 内存，避免 fork 过慢。

合理配置 Linux 内存分配策略：vm.overcommit_memory=1。fork 时如果内存不够，会阻塞。Linux 的vm.overcommit_memory 默认为 0，不会分配额外内存。

子进程开销和优化

        bgsave 和 bgrewriteaof 会进行 fork 操作产生子进程。

        CPU

        开销：RDB 和 AOF 文件生成属于 CPU 密集型。

        优化：不做 CPU 绑定，不和 CPU 密集型应用部署在一起。

        内存

        开销：fork 内存开销。

        优化：echo never /sys/kernel/mm/transparent_hugepage/enabled。

        硬盘

        开销：AOF 和 RDB 文件写入，可以结合 iostat 和 iotao 分析。

        优化：

1. 1. • 不要和高硬盘负载服务部署在一起：存储服务、消息队列；
      • no-appendfsync-on-rewrite=yes；
      • 根据写入量决定磁盘类型：例如 sdd；
      • 单机多实例持久化文件目录可以考虑分盘；

   AOF 追加阻塞

   

   阻塞定位

           Redis日志

   

           info persistence 可以查看上述日志发生的次数。

   

           优化：同子进程的硬盘优化。

    

    

   参考：

           http://doc.redisfans.com/topic/persistence.html

           慕课网：一站式学习Redis 从入门到高可用分布式实践

   原文始发于微信公众号（一个八月想偷懒的开发坑）：