Redis的持久化机制

我们知道Redis与传统数据库的一个主要区别就在于Redis把所有数据都存储在内存当中，而传统数据库通常只会把数据的索引存储在内存中，并将实际的数据存储在磁盘中。虽然Redis的数据存储方式使得用户可以以极快的速度读写服务器中的数据，但由于内存属于易失存储，如果系统断电后它记录的所有数据就会丢失，使数据变得不安全。

为了解决数据安全性的问题，Redis提供了数据持久化的功能，这一功能可以把内存中的数据以文件的形式存储在磁盘中，就算服务器发生问题导致宕机之后也可以恢复原有的数据，保证数据安全。

Redis持久化存储有两种持久化方案，分别是RDB和AOF。其中RDB是将内存中数据的快照存储到磁盘内，AOF则是通过日志记录Redis内的所有操作。在Redis 4之后还支持AOF+RDB混合持久化的方式，结合了两者的优点。

RDB持久化介绍：

RDB是将Redis内存中数据的快照存储在磁盘内，是Redis的默认持久化方案。持久化产生的文件都以.rdb后缀结尾，其中rdb代表Redis数据库，每当Redis服务重启的时候都会从该文件中把数据加载到内存中。

Redis提供了多种方式创建rdb文件，可以使用save命令或者bgsave命令来手动创建rdb文件，也可以通过设置redis.conf配置文件中的save选项让服务器在满足指定条件下自动执行bgsave命令自动生成rdb文件。

1.使用save命令

save命令会要求redis服务器以同步的方式创建出一个记录了当前redis中所有数据库的rdb文件。在执行save命令期间redis服务将阻塞，直到rdb文件创建成功为止。如果在执行save命令时rdb文件已经存在，那么服务器会使用新的rdb文件替换已有的rdb文件。

 

2.使用bgsave命令

因为save命令在执行时会阻塞整个redis服务，所以redis在使用该命令创建rdb文件期间将无法为其他用户端提供服务。为了解决这个问题，Redis提供了save命令的异步版本bgsave命令。bgsave命令会要求redis服务器以异步的方式创建出一个记录了当前redis中所有数据库的rdb文件。因为bgsave命令是以异步方式执行的，所以Redis服务器在bgsave命令执行期间仍然可以继续处理其他用户端发送的命令请求。

3.修改配置文件

通过在/etc/redis.conf配置文件中设置save选项，可以让Redis服务器在满足指定条件时自动执行bgsave命令。Redis允许同时向服务器提供多个save选项，当给定选项中的任意一个条件被满足时，服务器就会执行一次bgsave。

配置项	说明
dbfilename dump.rdb	设置持久化rdb文件名，默认为dump.rdb
dir /var/lib/redis	设置持久化rdb文件存储位置，默认存在在/var/lib/redis目录下
save 900 1 save 300 10 save 60 10000	900秒内至少有一次修改则触发保存操作 300秒内至少有10次修改则触发保存操作 60秒内至少有1万次修改则触发保存操作

RDB持久化依然存在一些问题，比如全量备份是非常耗时的过程，并且不能提供强一致性，还有如果Redis服务进程崩溃，那么在最近一次RDB备份之后的数据也会随之消失，也存在数据丢失的风险。

AOF持久化介绍：

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

通过修改/etc/redis.conf配置文件开启AOF持久化：

配置项	说明
save ""	禁用RDB持久化机制
appendonly yes	配置是否启用AOF持久化机制，yes表示启用AOF机制，no表示禁用AOF机制
appendfilename "appendonly.aof"	设置持久化aof文件名，默认为appendonly.aof
dir /var/lib/redis	设置持久化aof文件存储位置，默认存在在/var/lib/redis目录下
appendfsync everysec	设置AOF触发机制，默认为everysec

参数中最重要的就是appendfsync这个设置AOF触发机制的参数，如果该参数值为always表示每次发生数据变更都会被立即记录到磁盘，这种方式性能较差，但数据完整性比较好。在使用always值的情况下，服务器在停机时最多只会丢失一个命令的数据，但使用这种方式将使Redis服务器的性能降低至传统关系数据库的水平。如果该参数值为everysec表示每1秒钟将aof_buf缓冲区的内容写入aof文件，如果宕机就会有1秒内的数据丢失。在使用everysec值的情况下，服务器在停机时最多只会丢失1s之内产生的命令数据，这是一种兼顾性能和安全性的折中方案。如果参数的值为no表示将数据同步操作交给操作系统来处理，这种方式性能最好，但是数据可靠性最差。在使用no值的情况下，服务器在停机时将丢失系统最后一次保存AOF文件之后产生的所有命令数据，至于数据量的具体大小则取决于系统保存AOF文件的频率。

注意当配置文件时没有将save选项设置为空字符串，那么此时AOF和RDB机制会并存，Redis会优先采用AOF机制，使用AOF持久化文件恢复内存中的数据。而AOF刚刚开启时appendonly.aof持久化文件中没有任何数据，拿空的aof持久化文件恢复内存就会导致开启AOF机制以前所有数据的丢失。

在AOF持久化模式下，每个写命令都会追加到aof文件中。随着对数据库的不断操作，aof文件会越来越大，为了避免aof产生的文件太大，服务器会对aof文件进行重写，将操作相同键的相同命令进行合并，从而减少该文件的大小。

AOF重写前	AOF重写后
set  count  1 incr  count incr  count incr  count	set  count  4

例如在AOF重写前执行了存储一个值为1的count键值对，并对count键对应的值执行了三次加1操作，那么就会在AOF文件中产生4条命令，其实最终的数据也就是count的值为4。所以在触发重写后aof文件内容变少，减小了体积。

可以通过执行BGREWRITEAOF命令显式地触发AOF重写操作，该命令是一个异步命令，Redis服务器在接收到该命令之后会创建出一个子进程，由它扫描整个数据库并生成新的aof文件。当新的aof文件生成完毕，子进程就会退出并通知Redis服务器（父进程），然后Redis服务器就会使用新的aof文件代替已有的aof文件，借此完成整个重写操作。

除了可以手动执行BGREWRITEAOF命令创建新的aof文件之外，还可以通过设置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size这两个配置选项让Redis自动触发BGREWRITEAOF命令。

auto-aof-rewrite-percentage默认设置值为100，表示如果当前aof文件的体积比最后一次aof文件重写之后的体积增大了一倍（100%），那么将自动执行一次BGREWRITEAOF命令。auto-aof-rewrite-min-size默认设置值为64mb，表示用于设置触发自动AOF文件重写所需的最小aof文件体积，当AOF文件的体积小于给定值时，服务器将不会自动执行BGREWRITEAOF命令。

RDB与AOF优缺点对比：

RDB持久化后的文件是二进制文件，更适用于备份、全量复制及灾难恢复，所有RDB恢复数据的性能要优于AOF恢复数据的性能。但是如果Redis所在服务器发生宕机，则会丢失最后一次快照后的所有修改，不能绝对保证数据的高度一致性和完整性。

与RDB持久化可能会丢失大量数据相比，AOF持久化的安全性要高得多。通过使用everysec选项，用户可以将数据丢失的时间窗口限制在1s之内。但是因为aof文件存储的是协议文本，所以它的体积会比包含相同数据二进制格式的rdb文件要大得多，并且生成aof文件所需的时间也会比生成rdb文件所需的时间更长。AOF持久化需要通过执行aof文件中保存的命令来恢复数据库，所以RDB持久化的数据恢复速度将比AOF持久化的数据恢复速度快得多，并且数据库体积越大，这两者之间的差距就会越明显。

文章作者：孙长凯，深信服大数据认证专家，产业教育中心资深讲师，曾就职于思特奇科技、天奕思益科技、千锋教育，分别担任分布式内存数据库研发工程师、大数据平台架构师、人工智能专家、学科主管以及多所高校特聘企业讲师；具有八年大数据、人工智能从业经验，在大数据人工智能领域、企业项目管理等方面有较强的实战经验，对大数据、人工智能相关技术课程具备丰富的课程交付经验。