Redis的持久化详解

一、RDB持久化

RDB持久化是Redis默认使用的持久化功能，该功能可以创建出一个经过压缩的二进制文件，其中包含了服务器在各个数据库中存储的键值对数据等信息。RDB持久化产生的文件都以．rdb后缀结尾，其中rdb代表Redis DataBase

命令

1.SAVE

SAVE
阻塞服务器并创建RDB文件

2.BGSAVE

BGSAVE
以非阻塞方式创建RDB文件

3.SAVE

用户除了可以使用SAVE命令和BGSAVE命令手动创建RDB文件之外，还可以通过设置save选项，让Redis服务器在满足指定条件时自动执行BGSAVE命令
SAVE <seconds> <changes>

save选项接受seconds和changes两个参数，前者用于指定触发持久化操作所需的时长，而后者则用于指定触发持久化操作所需的修改次数。简单来说，如果服务器在seconds秒之内，对其包含的各个数据库总共执行了至少changes次修改，那么服务器将自动执行一次BGSAVE命令。

数据丢失

1. SAVE命令的停机情况

因为SAVE命令是一个同步操作，它的开始和结束都位于同一个原子时间之内，所以如果用户使用SAVE命令进行持久化，那么服务器在停机时将丢失最后一次成功执行SAVE命令之后产生的所有数据。

2. BGSAVE命令的停机情况

因为BGSAVE命令是一个异步命令，它的开始和结束并不位于同一个原子时间之内，所以如果用户使用BGSAVE命令进行持久化，那么服务器在停机时丢失的数据量将取决于最后一次成功执行的BGSAVE命令的开始时间。

3. RDB持久化的缺陷

总的来说，无论用户使用的是SAVE命令还是BGSAVE命令，停机时服务器丢失的数据量将取决于创建RDB文件的时间间隔：间隔越长，停机时丢失的数据也就越多。然而矛盾之处在于，RDB持久化是一种全量持久化操作，它在创建RDB文件时需要存储整个服务器包含的所有数据，并因此消耗大量计算资源和内存资源，所以用户是不太可能通过增大RDB文件的生成频率来保证数据安全的。
从RDB持久化的特征来看，它更像是一种数据备份手段而非一种普通的数据持久化手段。

二、AOF持久化

与全量式的RDB持久化功能不同，AOF提供的是增量式的持久化功能，这种持久化的核心原理在于：服务器每次执行完写命令之后，都会以协议文本的方式将被执行的命令追加到AOF文件的末尾。这样一来，服务器在停机之后，只要重新执行AOF文件中保存的Redis命令，就可以将数据库恢复至停机之前的状态。

命令

1.appendonly

appendonly <value>
如果用户想要开启AOF持久化功能，那么只需要将这个值设置为yes即可
反之，如果用户想要关闭AOF持久化功能，那么只需要将这个值设置为no即可

2.appendfsync

为了提高程序的写入性能，现代化的操作系统通常会把针对硬盘的多次写操作优化为一次写操作。具体的做法是，当程序调用write系统调用对文件进行写入时，系统并不会直接把数据写入硬盘，而是会先将数据写入位于内存的缓冲区中，等到指定的时限到达或者满足某些写入条件时，系统才会执行flush系统调用，将缓冲区中的数据冲洗至硬盘。这种优化机制虽然提高了程序的性能，但是也给程序的写入操作带来了不确定性，特别是对于AOF这样的持久化功能来说，AOF文件的冲洗机制将直接影响AOF持久化的安全性。为了消除上述机制带来的不确定性，Redis向用户提供了appendfsync选项，以此来控制系统冲洗AOF文件的频率

appendfsync <value>

appendfsync选项拥有always、everysec和no 3个值可选，它们代表的意义分别为：
●always——每执行一个写命令，就对AOF文件执行一次冲洗操作。
●everysec——每隔1s，就对AOF文件执行一次冲洗操作。
●no——不主动对AOF文件执行冲洗操作，由操作系统决定何时对AOF进行冲洗。

这3种不同的冲洗策略不仅会直接影响服务器在停机时丢失的数据量，还会影响服务器在运行时的性能：
●在使用always值的情况下，服务器在停机时最多只会丢失一个命令的数据，但使用这种冲洗方式将使Redis服务器的性能降低至传统关系数据库的水平。
●在使用everysec值的情况下，服务器在停机时最多只会丢失1s之内产生的命令数据，这是一种兼顾性能和安全性的折中方案。
●在使用no值的情况下，服务器在停机时将丢失系统最后一次冲洗AOF文件之后产生的所有命令数据，至于数据量的具体大小则取决于系统冲洗AOF文件的频率。因为no策略给可能丢失的数据量带来了不确定性，而always策略对于安全性的追求又牺牲了服务器的性能，所以Redis使用everysec作为appendfsync选项的默认值。除非有明确的需求，否则用户不应该随意修改appendfsync选项的值。

3.BGREWRITEAOF

BGREWRITEAOF
用户可以通过执行BGREWRITEAOF命令显式地触发AOF重写操作，该命令是一个无参数命令

用户除了可以手动执行BGREWRITEAOF命令创建新的AOF文件之外，还可以通过设置以下两个配置选项让Redis自动触发BGREWRITEAOF命令

4.auto-aof-rewrite-min-size

auto-aof-rewrite-min-size <value>
其中auto-aof-rewrite-min-size选项用于设置触发自动AOF文件重写所需的最小AOF文件体积，当AOF文件的体积小于给定值时，服务器将不会自动执行BGREWRITEAOF命令。
在默认情况下，该选项的值为：
auto-aof-rewrite-min-size 64mb

5.auto-aof-rewrite-percentage

auto-aof-rewrite-percentage <value>

auto-aof-rewrite-percentage 100
表示如果当前AOF文件的体积比最后一次AOF文件重写之后的体积增大了一倍（100%），那么将自动执行一次BGREWRITEAOF命令。如果Redis服务器刚刚启动，还没有执行过AOF文件重写操作，那么启动服务器时使用的AOF文件的体积将被用作最后一次AOF文件重写的体积。

AOF持久化的优缺点

与RDB持久化可能会丢失大量数据相比，AOF持久化的安全性要高得多：通过使用everysec选项，用户可以将数据丢失的时间窗口限制在1s之内。但是与RDB持久化相比，AOF持久化也有相应的缺点：
●首先，因为AOF文件存储的是协议文本，所以它的体积会比包含相同数据、二进制格式的RDB文件要大得多，并且生成AOF文件所需的时间也会比生成RDB文件所需的时间更长。
●其次，因为RDB持久化可以直接通过RDB文件恢复数据库数据，而AOF持久化则需要通过执行AOF文件中保存的命令来恢复数据库（前者是直接的数据恢复操作，而后者则是间接的数据恢复操作），所以RDB持久化的数据恢复速度将比AOF持久化的数据恢复速度快得多，并且数据库体积越大，这两者之间的差距就会越明显。
●最后，因为AOF重写使用的BGREWRITEAOF命令与RDB持久化使用的BGSAVE命令一样都需要创建子进程，所以在数据库体积较大的情况下，进行AOF文件重写将占用大量资源，并导致服务器被短暂地阻塞。

三、RDB-AOF混合持久化

aof-use-rdb-preamble

aof-use-rdb-preamble <value>
选项的值设置成了yes，那么Redis服务器在执行AOF重写操作时，就会像执行BGSAVE命令那样，根据数据库当前的状态生成出相应的RDB数据，并将这些数据写入新建的AOF文件中，至于那些在AOF重写开始之后执行的Redis命令，则会继续以协议文本的方式追加到新AOF文件的末尾，即已有的RDB数据的后面。换句话说，在开启了RDB-AOF混合持久化功能之后，服务器生成的AOF文件将由两个部分组成，其中位于AOF文件开头的是RDB格式的数据，而跟在RDB数据后面的则是AOF格式的数据

当一个支持RDB-AOF混合持久化模式的Redis服务器启动并载入AOF文件时，它会检查AOF文件的开头是否包含了RDB格式的内容：
●如果包含，那么服务器就会先载入开头的RDB数据，然后再载入之后的AOF数据。
●如果AOF文件只包含AOF数据，那么服务器将直接载入AOF数据。

但是Redis的作者声称，RDB-AOF混合持久化将在未来取代传统的RDB持久化成为Redis默认的持久化模式。

四、无持久化

如果用户想要彻底关闭这一默认的RDB持久化行为，让Redis服务器处于完全的无持久化状态，那么可以在服务器启动时向它提供以下配置选项
save ""