redis持久化选择

    Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。一种方法叫快照（snapshot-ting），它可以将存在于某一时刻的所有数据都写入硬盘里面。另一种方法叫只追加文件（append-onlyfile，AOF），它会在执行写命令时，将被执行的写命令复制到硬盘里面。这两种持久化方法既可以同时使用，又可以单独使用，在某些情况下甚至可以两种方法都不使用，具体选择哪种持久化方法需要根据用户的数据以及应用来决定。

两种方式常见的命令如下图：

快照：多久执行一次自动快照操作、是否对快照文件进行压缩，以及在创建快照失败后是否仍然继续执行写命令、如何命名硬盘上的快照文件

AOF：是否开启aof、多久执行一次自动快照操作、是否对快照文件进行压缩，以及在创建快照失败后是否仍然继续执行写命令、压缩重写的条件、如何命名硬盘上的快照文件

一.快照

    Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器时使用。

创建快照的办法有以下几种。  

1.客户端可以通过向Redis发送BGSAVE命令来创建一个快照。对于支持BGSAVE命令的平台来说（基本上所有平台都支持，除了Win-dows平台），Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。

2.客户端还可以通过向Redis发送SAVE命令来创建一个快照，接到SAVE命令的Redis服务器在快照创建完毕之前将不再响应任何其他命令。SAVE命令并不常用，我们通常只会在没有足够内存去执行BGSAVE命令的情况下，又或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令。

3.如果用户设置了save配置选项，比如save60 10000，那么从Redis最近一次创建快照之后开始算起，当“60秒之内有10000次写入”这个条件被满足时，Redis就会自动触发BGSAVE命令。如果用户设置了多个save配置选项，那么当任意一个save配置选项所设置的条件被满足时，Redis就会触发一次BGSAVE命令。

4.当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在SAVE命令执行完毕之后关闭服务器。

5.当一个Redis服务器连接另一个Redis服务器，并向对方发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有在执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令。在只使用快照持久化来保存数据时，一定要记住：如果系统真的发生崩溃，用户将丢失最近一次生成快照之后更改的所有数据。因此，快照持久化只适用于那些即使丢失一部分数据也不会造成问题的应用程序，而不能接受这种数据损失的应用程序则可以考虑下面的AOF。

二.AOF持久化

AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化。因此，Redis只要从头到尾重新执行一次AOF文件包含的所有写命令，就可以恢复AOF文件所记录的数据集。AOF持久化可以通过设置appendonly yes配置选项来打开。

下图是appendfsync的几个选项：

为了兼顾数据安全和写入性能，用户可以考虑使用appendfsync everysec选项，让Redis以每秒一次的频率对AOF文件进行同步。Redis每秒同步一次AOF文件时的性能和不使用任何持久化特性时的性能相差无几，而通过每秒同步一次AOF文件，Redis可以保证，即使出现系统崩溃，用户也最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis还会优雅地放慢自己的速度以便适应硬盘的最大写入速度。

 

最后，如果用户使用appendfsync no选项，那么Redis将不对AOF文件执行任何显式的同步操作，而是由操作系统来决定应该在何时对AOF文件进行同步。这个选项在一般情况下不会对Redis的性能带来影响，但系统崩溃将导致使用这种选项的Redis服务器丢失不定数量的数据。另外，如果用户的硬盘处理写入操作的速度不够快的话，那么当缓冲区被等待写入硬盘的数据填满时，Redis的写入操作将被阻塞，并导致Redis处理命令请求的速度变慢。因为这个原因，一般来说并不推荐使用appendfsync no选项，在这里介绍它只是为了完整列举appendfsync选项可用的3个值。

 

虽然AOF持久化非常灵活地提供了多种不同的选项来满足不同应用程序对数据安全的不同要求，但AOF持久化也有缺陷——那就是AOF文件的体积大小。

 

备注：

当aof文件体积变大的时候就可以考虑重写/压缩AOF文件：

AOF持久化既可以将丢失数据的时间窗口降低至1秒（甚至不丢失任何数据），又可以在极短的时间内完成定期的持久化操作，那么我们有什么理由不使用AOF持久化呢？但是这个问题实际上并没有那么简单，因为Redis会不断地将被执行的写命令记录到AOF文件里面，所以随着Redis不断运行，AOF文件的体积也会不断增长，在极端情况下，体积不断增大的AOF文件甚至可能会用完硬盘的所有可用空间。还有另一个问题就是，因为Redis在重启之后需要通过重新执行AOF文件记录的所有写命令来还原数据集，所以如果AOF文件的体积非常大，那么还原操作执行的时间就可能会非常长。

为了解决AOF文件体积不断增大的问题，用户可以向Redis发送BGREWRITEAOF命令，这个命令会通过移除AOF文件中的冗余命令来重写（rewrite）AOF文件，使AOF文件的体积变得尽可能地小。BGREWRITEAOF的工作原理和BGSAVE创建快照的工作原理非常相似：Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写。因为AOF文件重写也需要用到子进程，所以快照持久化因为创建子进程而导致的性能问题和内存占用问题，在AOF持久化中也同样存在。更糟糕的是，如果不加以控制的话，AOF文件的体积可能会比快照文件的体积大好几倍，在进行AOF重写并删除旧AOF文件的时候，删除一个体积达到数十GB大的旧AOF文件可能会导致操作系统挂起（hang）数秒。

跟快照持久化可以通过设置save选项来自动执行BGSAVE一样，AOF持久化也可以通过设置auto-aof-rewrite-percentage选项和auto-aof-rewrite-min-size选项来自动执行BGREWRITEAOF。举个例子，假设用户对Redis设置了配置选项auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb，并且启用了AOF持久化，那么当AOF文件的体积大于64MB，并且AOF文件的体积比上一次重写之后的体积大了至少一倍（100%）的时候，Redis将执行BGREWRITEAOF命令。如果AOF重写执行得过于频繁的话，用户可以考虑将auto-aof-rewrite-per-centage选项的值设置为100以上，这种做法可以让Redis在AOF文件的体积变得更大之后才执行重写操作，不过也会让Redis在启动时还原数据集所需的时间变得更长。