redis 持久化

redis 持久化

Redis 提供了多种不同级别的持久化方式：

• RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
• AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
• Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
• 你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

了解 RDB 持久化和 AOF 持久化之间的异同是非常重要的， 以下几个小节将详细地介绍这这两种持久化功能， 并对它们的相同和不同之处进行说明。

RDB

优点：

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

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

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

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

缺点

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

2 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。因为fork进程会复制父进程的内存到子进程的内存空间，现在的操作系统提供COW, 当fork一个子进程时，只会复制父进程的内存页表到子进程，即子进程和父进程共享一个内存页表， 但是当父进程修改自己的内存时候， 操作系统就会在修改之前复制将要修改的父进程内存空间到子进程的内存空间，同时更新子进程的内存页表，保证子进程的内存不受父进程修改内存影响。

实现

有两个命令可以用于生成RDB文件，一个是SAVE, 另一个是BGSAVE。

SAVE命令会阻塞 redis 服务器进程，知道RDB文件创建完成为止， 在服务器进程阻塞期间， 服务器不能处理任何命令请求。

和SAVE命令直接阻塞服务进程不同， BGSAVE 命令会派生出一个子进程， 然后由子进程负责创建 RDB 文件， 服务器进程可以继续处理命令请求。

还原过程中都是在服务器启动的时候进行还原， 具体在server.c/initServe( )中进行，因为RDB文件的数据丢失率较 AOF 高， 所以如果服务器开启了 AOF 持久功能，则使用 AOF 来还原数据库， 只有在 AOF 持久功能关闭状态时， 服务器才会使用 RDB 文件来还原数据库。

AOF

优点：

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

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

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

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

缺点

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

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

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

实现

redis 服务器进程时一个事件循环， 这个事件循环的文件事件负责接收客户端的命令请求， 以及向客户端发送命令回复， 而时间事件则负责像serverCoron函数这样需要定时运行的函数。

因为服务器在处理文件事件时可能会执行写命令， 是的一些内容被追加到aof_buf 缓冲区里面， 所以服务器每次结束一个事件循环之前， 它都会调用flushAppendOnlyFile 考虑是否需要将aof_buf 缓冲区的内容写入保存AOF文件里面。flushAppendOnlyFile函数的行为由服务器配置的appendfsync选项的值来决定： (1) always：将aof_buf缓冲区的所有内容写入并同步到AOF文件，(2) everysec：将aof_buf缓冲区中的所有内容写入到AOF文件， 如果上次绒布AOF文件时间距离现在超过一秒钟， 那么再次对AOF文件进行同步，并且这个操作是由一个线程专门负责的, (3) no：将aof_buf缓冲区的所有内容写入到AOF文件， 但并不对AOF文件进行同步， 何时同步由操作系统决定。（写入和同步参考操作系统对数据写入到磁盘的过程）

AOF因为一段时间内对数据多次写入，所以文件会过大，一般会进行重写，比如对一个键修改三次，那么重写的过程中只需要记录前三次修改之后的状态即可，AOF重写并不需要对现有的AOF文件进行任何的读取， 分析， 或者写入操作， 这个功能是通过读取当前的数据库状态来实现的，AOF重写过程是由子进程来进行的，所以服务器进程会继续处理命令请求， 过程如下:

• AOF 缓冲区的内容会定期被写入和同步到AOF文件， 对现有的AOF处理工作会如常进行。

• 从创建子进程开始， 服务器执行的所有命令都会记录到AOF重写缓冲区里面。

• 当子线程完成AOF重写工作之后， 它会向父进程发送一个信号， 父进程在接到该信号之后， 会调用一个阻塞处理函数， 并执行以下工作：

  （1） 将AOF重写缓冲区的所有内容写入到新AOF文件中， 这时新AOF文件所保存的数据库将和当前数据库状态一致

  （2） 对新的AOF文件进行改名， 原子地覆盖现有的AOF文件， 完成新旧两个AOF文件的替换。

• 这个信号处理函数执行完毕之后，父进程就可以继续处理命令请求了。

参考：

• http://redisdoc.com/topic/persistence.html
• 《Redis设计与实现》