Redis的持久化

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

RDB持久化可以在指定的时间间隔内生成数据集的时间点快照。

AOF持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。AOF文件中的命令全部以Redis协议的格式来保存，新命令会被追加到文件的末尾。

可以同时使用AOF持久化和RDB持久化，当Redis重启时，会优先使用AOF文件来还原数据集，因为AOF文件所保存的数据通常是最完整的。

RDB的优点

RDB是一个非常紧凑的文件，它保存了Redis在某个时间点上的数据集，非常适合用于进行备份。

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

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

RDB的缺点

在数据集比较庞大时，fork()可能会非常耗时，造成服务器在某段时间内停止处理客户端;

每隔一段时间才保存一次RDB文件，在这种情况下，一旦发生故障停机，你就可能会丢失好这段时间的数据。

AOF的优点

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

AOF文件是一个只进行追加操作的日志文件，因此对AOF文件的写入不需要进行seek，即使因为某些原因而包含了未写入完整的命令，redis-check-aof工具也可以轻易地修复这种问题。

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

AOF的缺点

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

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

AOF文件重写

Redis可以在后台对AOF文件进行重写，重写后新AOF文件包含了恢复当前数据集所需的最小命令集合。

以下是 AOF 重写的执行步骤：

    Redis执行fork() ，现在同时拥有父进程和子进程。 
    子进程开始将新AOF文件的内容写入到临时文件。 
    对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有的旧AOF文件的末尾。 
    当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新AOF文件的末尾。 
    最后Redis原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

服务器在AOF功能开启的情况下，会维持以下三个变量：

    记录当前AOF文件大小的变量aof_current_size
    记录最后一次AOF重写之后，AOF文件大小的变量aof_rewrite_base_size
    自最后一次重写之后AOF文件增长的百分比变量aof_rewrite_perc

配置文件中指定自动重写的AOF文件最小体积和自最后一次重写之后AOF文件增长的百分比，当两个条件都满足时会自动进行AOF文件重写

    auto-aof-rewrite-min-size：自动运行AOF重写时AOF文件最小体积，默认为67108864(64MB)
    auto-aof-rewrite-percentage：自最后一次重写之后AOF文件增长的百分比大于指定值才进行自动AOF重写,默认值100(不包含百分号)

RDB和AOF之间的相互作用

在版本号大于等于2.4的Redi中，bgsave和bgrewriteaof不可以同时执行。防止两个Redis后台进程同时对磁盘进行大量的I/O操作。

如果其中一个正在执行， 并且用户显示地调用另一个命令， 那么服务器将向用户回复一个OK状态， 并告知用户，另一个已经被预定执行

持久化命令：

bgrewriteaof：AOF文件重写命令(创建一个当前AOF文件的体积优化版本)，如果已经有别的AOF文件重写在执行，那么返回一个错误

save

    执行一个同步保存操作，将当前Redis实例的所有数据快照以rob文件的形式保存到硬盘
    一般来说，在生产环境很少执行save操作，因为它会阻塞所有客户端，保存数据库的任务通常由bgsave命令异步地执行。
    如果负责保存数据的后台子进程不幸出现问题时，save可以作为保存数据的最后手段来使用。
    保存成功时返回OK

bgsave

    在后台异步(Asynchronously)保存当前数据库的数据到磁盘
    命令执行之后立即返回OK，然后fork出一个新子进程，负责将数据保存到磁盘，然后退出
    客户端可以通过lastsave命令查看相关信息，判断BGSAVE命令是否执行成功

lastsave：返回最近一次成功将数据保存到磁盘上的时间，以UNIX时间戳格式表示

混合持久化：

因为RDB持久化无法实时保存数据，而AOF持久化在恢复数据时需要大量时间，因此Redis在4.0版本推出RDB-AOF混合持久化。

aof-use-rdb-preamble：该参数配置是否开启混合持久化(yes|no)，4.0版本默认关闭，5.0版本默认开启。

混合持久化其实就像是一种RDB&AOF的结合，持久化文件(aof文件)内容格式变成了RDB+AOF，首先由RDB定期完成内存快照的备份，然后再由AOF完成两次RDB之间的数据备份。

混合持久化开启后，系统根据策略触发aof rewrite时，通过执行bgrewriteaof命令fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后再将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。

简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据，这样就充分了利用了RDB加载快，备份文件小等特点，也利用了AOF能尽可能不丢数据这个特性。

这样也基本上丢失了AOF的可读性。

恢复数据时按部分进行加载，先按照前面RDB部分进行加载，然后把后面的AOF记录的命令追加写入。