Redis--持久化（RDB/AOF）

转自https://www.cnblogs.com/wind-snow/p/11287662.html

因为 Redis 是内存数据库，它将自己的数据储存在内存里面，所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据也将会丢失，为了解决这个问题，Redis 提供了持久化的功能。

Redis 中的持久化有两种，分别是 RDB 和 AOF。

RDB 持久化

RDB 是将 Redis 内存中的快照直接保存到磁盘中，避免数据丢失。

RDB 文件的创建

RDB 文件是一个经过压缩的二进制文件。有两个命令可以生产 RDB 文件，一个是 SAVE，另一个是 BGSAVE（BackGroundSave）。
SAVE 命令会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。
BGSAVE 命令会派生出一个子进程，然后由子进程负责创建 RDB 文件，服务器进程（父进程）继续处理命令请求。

除了主动执行命令之外，Redis 还可以根据配置自动进行 RDB 持久化。如果我们向服务器有如下配置（默认就有）：
save 900 1
save 300 10
save 60 10000
那么只要满足以下三个条件中的任意一个，BGSAVE 命令就会被执行：

• 服务器在 900 秒之内，对数据库进行了至少 1 次修改。
• 服务器在 300 秒之内，对数据库进行了至少 10 次修改。
• 服务器在 60 秒之内，对数据库进行了至少 10000 次修改。

RDB 文件的载入

RDB 文件的载入工作是在服务器启动时自动执行的，所以 Redis 并没有专门用于载入 RDB 文件的命令，只要 Redis 服务器在启动时检查到 RDB 文件，就会自动载入。

另外值得一提的是，因为 AOF 文件的更新频率通常比 RDB 文件的更新频率高，所以：

• 如果服务器开启了 AOF 持久化功能，那么服务器会优先使用 AOF 文件来还原数据库状态。
• 只有在 AOF 持久化功能处于关闭状态时，服务器才会使用 RDB 文件来还原数据库状态。
  如下图所示（出自《Redis设计与实现第二版》第十章：RDB持久化）：

• RDB文件用于保存和还原Redi服务器所有数据库中的所有键值对数据。
• SAVE命令由服务器进程直接执行保存操作,所以该命令会阻塞服务器。
• BGSAVE令由子进程执行保存操作,所以该命令不会阻塞服务器。
• 服务器状态中会保存所有用save选项设置的保存条件,当任意一个保存条件被满足时,服务器会自动执行 BGSAVE命令
• RDB文件是一个经过压缩的二进制文件,由多个部分组成。对于不同类型的键值对,RDB文件会使用不同的方式来保存它们。

RDB文件载入时服务器的状态

服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止

三、dirty计数器和lastsave属性
struct redisServer {
　　// ...
　　long long dirty;//修改计数器
　　time_t lastsave;//上一次执行保存的时间
　　// ...
};
除了saveparams数组之外，服务器状态还维持着一个dirty计数器，以及一个lastsave属性：

dirty计数器记录距离上一次成功执行SAVE命令或者BGSAVE命令之后，服务器对数据库状态（服务器中的所有数据库）进行了多少次修改（包括写入、删除、更新等操作）
lastsave属性是一个UNIX时间戳，记录了服务器上一次成功执行SAVE命令或者BGSAVE命令的时间
当服务器成功执行一个数据库修改命令之后，程序就会对dirty计数器进行更新：命令修改了多少次数据库，dirty计数器的值就增加多少。例如，我们向一个集合键增加3个新元素，那么dirty计数器的值增加3

AOF 持久化

和 RDB 持久化不同，AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库状态的，如下图所示（出自《Redis设计与实现第二版》第十一章：AOF持久化）：

AOF 持久化的实现

当 AOF 持久化功能处于打开状态时，服务器在执行完一个写命令之后，会将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。

AOF 持久化的效率和安全性
服务器配里 appendfsync 选项的值直接决定 AOF 持久化功能的效率和安全性。

• 当 appendfsyn 的值为 always 时，服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，并且同步 AOF 文件，所以 always 的效率是 aPPendfsync 选项三个值当中最慢的一个，但从安全性来说， always 也是最安全的，因为即使出现故障停机， AOF 持久化也只会丢失一个事件循环中所产生的命令数据。
• 当 appendfsync 的值为 everysec 时，服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，并且每隔一秒就要在子线程中对 AOF 文件进行一次同步。从效率上来讲， everysec 模式足够快，并且就算出现故障停机，数据库也只丢失一秒钟的命令数据。
• 当 appendfsync 的值为 no 时，服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，至于何时对 AOF 文件进行同步，则由操作系统控制。因为处于 no 模式下的 flushAppendonlyFile 调用无须执行同步操作，所以该模式下的 AOF 文件写入速度总是最快的，不过因为这种模式会在系统缓存中积取一段时间的写入数据，所以该模式的单次同步时长通常是三种模式中时间最长的。从平摊操作的角度来看， no 模式和 everysec 模式的效率类似，当出现故障停机时，使用 no 模式的服务器将丢失上次同步 AOF 文件之后的所有写命令数据。

AOF 文件的载入与数据还原

因为 AOF 文件里面包含了重建数据库状态所需的所有写命令， 所以服务器只要读入并重新执行一遍 AOF 文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。

AOF 文件载入过程如下（出自《Redis设计与实现第二版》第十一章：AOF持久化）：

AOF 文件的重写

因为 AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝， AOF 文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的 AOF 文件很可能对 Redis 服务器、甚至整个宿主计算机造成影响，并且 AOF 文件的体积越大，使用 AOF 文件来进行数据还原所需的时间就越多。

为了解决 AOF 文件体积过大的问题，Redis 提供了 AOF 文件重写功能。即服务器可以创建一个新的 AOF 文件来代替现有的 AOF 文件，但由于新的 AOF 文件不会包含任何浪费空间的冗余命令（即只有写命令，没有del命令等），所以新 AOF 文件的体积通常比旧 AOF 文件的体积小得多。

需要注意的是，服务器不是去读取和分析现有AOF文件的内容，而是直接获取数据库状态中的键值对，用类似Add的方式生成命令。比如对于某个键，原AOF生成了6条写入命令（不断更新），新AOF直接根据现有的键值直接生成一条写入命令。

AOF是放在子进程中进行的，当子进程完成AOF重写工作之后,它会向父进程发送一个信号,父进程在接到该信号之后,会调用一个信号处理函数,并执行以下工作

1)将AOF重写缓冲区中的所有内容写人到新AOF文件中,这时新AOF文件所保存的数据库状态将和服务器当前的数据库状态一致。

2)对新的AOF文件进行改名,原子地( atomic)覆盖现有的AOF文件,完成新旧两个AOF文件的替换。这个信号处理函数执行完毕之后,父进程就可以继续像往常一样接受命令请求了。
在整个AOF后台重写过程中,只有信号处理函数执行时会对服务器进程(父进程)造成阻塞,在其他时候,AOF后台重写都不会阻塞父进程,这将AOF重写对服务器性能造成的影响降到了最低。

总结：

• AOF文件通过保存所有修改数据库的写命令请求来记录服务器的数据库状态。
• AOF文件中的所有命令都以 Redis命令请求协议的格式保存。
• 命令请求会先保存到AOF缓冲区里面,之后再定期写入并同步到AOF文件。
• appendfsync选项的不同值对AOF持久化功能的安全性以及 Redis服务器的性能有很大的影响。
• 服务器只要载入并重新执行保存在AOF文件中的命令,就可以还原数据库本来的状态。
• AOF重写可以产生一个新的AOF文件,这个新的AOF文件和原有的AOF文件所保存的数据库状态一样,但体积更小。
• AOF重写是一个有歧义的名字,该功能是通过读取数据库中的键值对来实现的,程序无须对现有AOF文件进行任何读入、分析或者写人操作。
• 在执行 BGREWRITEAOF命令时, Redis服务器会维护一个AOF重写缓冲区,该缓冲区会在子进程创建新AOF文件期间,记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后,服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾,使得新旧两个AOF文件所保存的数据库状态一致。最后,服务器用新的AOF文件替换旧的AOF文件,以此来完成AOF文件重写操作。