Redis 持久化存储方案

　　从严格意义上说，Redis服务提供四种持久化存储方案：RDB、AOF、虚拟内存（VM）和　DISKSTORE。虚拟内存（VM）方式，从Redis Version 2.4开始就被官方明确表示不再建议使用，Version 3.2版本中更找不到关于虚拟内存（VM）的任何配置范例，Redis的主要作者Salvatore Sanfilippo还专门写了一篇论文，来反思Redis对虚拟内存（VM）存储技术的支持问题。

　　至于DISKSTORE方式，是从Redis Version 2.8版本开始提出的一个存储设想，到目前为止Redis官方也没有在任何stable版本中明确建议使用这用方式。在Version 3.2版本中同样找不到对于这种存储方式的明确支持。从网络上能够收集到的各种资料来看，DISKSTORE方式和RDB方式还有着一些千丝万缕的联系，不过各位读者也知道，除了官方文档以外网络资料很多就是大抄。

　　最关键的是目前官方文档上能够看到的Redis对持久化存储的支持明确的就只有两种方案（https://redis.io/topics/persistence）：RDB和AOF。所以本文也只会具体介绍这两种持久化存储方案的工作特定和配置要点。

RDB

　　RDB中文名为快照/内存快照，它的过程很好理解，就是Redis按照一定的时间周期将目前服务中的所有数据全部写入到磁盘中。但这个过程说起简单，实际上呢有很多细节需要被处理。Redis主配置文件的“REPLICATION”部分，放置了对这个过程的配置选项。

　　上图反映了内存快照的大致过程，由于生产环境中我们为Redis开辟的内存区域都比较大（例如6GB），那么将内存中的数据同步到硬盘的过程可能就会持续比较长的时间，而实际情况是这段时间Redis服务一般都会收到数据写操作请求。那么如何保证数据一致性呢？RDB中的核心思路是Copy-on-Write，来保证在进行快照操作的这段时间，需要压缩写入磁盘上的数据在内存中不会发生变化。在正常的快照操作中，一方面Redis主进程会fork一个新的快照进程专门来做这个事情，这样保证了Redis服务不会停止对客户端包括写请求在内的任何响应。另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域，待快照操作结束后才会同步到原来的内存区域。

　　另一个问题是，在进行快照操作的这段时间，如果发生服务崩溃怎么办？很简单，在没有将数据全部写入到磁盘前，这次快照操作都不算成功。如果出现了服务崩溃的情况，将以上一次完整的RDB快照文件作为恢复内存数据的参考。也就是说，在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行数据操作，待操作成功后才会用这个临时文件替换掉上一次的备份。

以下是Redis中关于内存快照的主要配置信息：

　　快照周期：内存快照虽然可以通过技术人员手动执行SAVE或BGSAVE命令来进行，但生产环境下多数情况都会设置其周期性执行条件。Redis中默认的周期新设置如下：

# 周期性执行条件的设置格式为
save  
# 默认的设置为：
save 900 1
save 300 10
save 60 10000
# 以下设置方式为关闭RDB快照功能
save ""

　　以上三项默认信息设置代表的意义是：如果900秒内有1条Key信息发生变化，则进行快照；如果300秒内有10条Key信息发生变化，则进行快照；如果60秒内有10000条Key信息发生变化，则进行快照。读者可以按照这个规则，根据自己的实际请求压力进行设置调整。

　　stop-writes-on-bgsave-error：上文提到的在快照进行过程中，主进程照样可以接受客户端的任何写操作的特性，是指在快照操作正常的情况下。如果快照操作出现异常（例如操作系统用户权限不够、磁盘空间写满等等）时，Redis就会禁止写操作。这个特性的主要目的是使运维人员在第一时间就发现Redis的运行错误，并进行解决。一些特定的场景下，您可能需要对这个特性进行配置，这时就可以调整这个参数项。该参数项默认情况下值为yes，如果要关闭这个特性，指定即使出现快照错误Redis一样允许写操作，则可以将该值更改为no。

　　rdbcompression：该属性将在字符串类型的数据被快照到磁盘文件时，启用LZF压缩算法。Redis官方的建议是请保持该选项设置为yes，因为“it’s almost always a win”。

　　rdbchecksum：从RDB快照功能的version 5 版本开始，一个64位的CRC冗余校验编码会被放置在RDB文件的末尾，以便对整个RDB文件的完整性进行验证。这个功能大概会多损失10%左右的性能，但获得了更高的数据可靠性。所以如果您的Redis服务需要追求极致的性能，就可以将这个选项设置为no。

　　dbfilename：RDB文件在磁盘上的名称。

　　dir：RDB文件的存储路径。默认设置为“./”，也就是Redis服务的主目录。

AOF

　　由于是周期性的同步，所以RDB存在的最大问题就是在Redis异常崩溃，需要从最近一次RDB文件恢复数据时，常常出现最近一批更新的数据丢失，而且根据快照的周期设置，这批数据的总量还可能比较大。另外，虽然使用专门的快照进程进行快照数据同步的方式，本身不会造成Redis服务出现卡顿。但如果需要快照的数据量特别大，操作系统基本上会将CPU资源用到快照操作上去，这可能间接造成包括Redis主进程在内的其它进程被挂起。所以，以一个较大的时间周期全部同步Redis数据状态的快照方式，在非常高并发的情况下并不是最好的解决方法。

　　虽然RDB快照基本上可以应付我们遇到的大多数业务场景，也可以满足至少80%业务系统设计时的预想性能压力，但为了尽可能解决RDB的工作缺陷，Redis还是提供了另一种数据持久化方式——AOF。AOF全称是Append Only File，从字面上理解就是“只进行增加的文件”。我们在介绍InnoDB的工作过程时，也介绍了类似“只进行增加的文件”，就是InnoDB中最关键的重做日志。

　　在物理磁盘的操作无论是机械磁盘还是固态磁盘，使用顺序读写都将获得比随机读写好得多的I/O性能。所以我们可以看到无论是关系型数据库、NoSQL数据库还是之前的业务案例，无一例外都追求在物理磁盘上尽可能进行顺序读写操作。

　　AOF方式的核心设计思量可以总结为一句话：忠实记录Redis服务启动成功后的每一次影响数据状态的操作命令，以便在Redis服务异常崩溃的情况出现时，可以按照这些操作命令恢复数据状态。既然要记录每次影响数据状态的操作命令，就意味着AOF文件会越来越大！这是必然的。还好Redis为AOF提供了一种重写AOF文件的功能，保证了AOF文件中可以存储尽可能少的操作命令就能保证数据恢复到最新状态，这个功能被称为日志重写功能（请注意这可不是我们在讲解InnoDB时提到的重做日志）。

　　举个例子，操作人员在Redis中设置了一个K-V结构：mykey3 = yinwenjie，之后有删除了这个Key信息。那么AOF文件中记录的动作可能如下所示（AOF文件中的内容可以直接通过各种文本编辑工具直接查看）：

# cat ./appendonly.aof
......
*3
$3
SET
$6
mykey3
$12
yinwenjie111
......
*2
$3
del
$6
mykey3
......

　　可以看到以上AOF文件中的内容，如实记录了这两个操作：设置Key和删除Key。但是这种日志记录过程对恢复Key的信息没有任何帮助，因为“mykey3”这个Key信息注定在最新的Redis内存中是不存在的。所以一旦我们运行“重写日志”命令（可以是设定的条件也可以直接运行“BGREWRITEAOF”命令），那么整理后的AOF文件的内容可能就是如下所示了：

# cat ./appendonly.aof
......
......

　　在AOF文件中对mykey3这个Key信息的操作过程记录消失了！这不但缩小了AOF文件还没有对数据恢复过程造成任何困扰。Redis主配置文件中关于AOF功能的设定可以在“APPEND ONLY MODE”部分找到：

以下是Redis中关于AOF的主要配置信息：

　　appendonly：默认情况下AOF功能是关闭的，将该选项改为yes以便打开Redis的AOF功能。

　　appendfilename：这个参数项很好理解了，就是AOF文件的名字。

　　appendfsync：这个参数项是AOF功能最重要的设置项之一，主要用于设置“真正执行”操作命令向AOF文件中同步的策略。

什么叫“真正执行”呢？还记得Linux操作系统对磁盘设备的操作方式吗？ 为了保证操作系统中I/O队列的操作效率，应用程序提交的I/O操作请求一般是被放置在linux Page Cache中的，然后再由Linux操作系统中的策略自行决定正在写到磁盘上的时机。而Redis中有一个fsync()函数，可以将Page Cache中待写的数据真正写入到物理设备上，而缺点是频繁调用这个fsync()函数干预操作系统的既定策略，可能导致I/O卡顿的现象频繁 。

　　appendfsync参数项可以设置三个值，分别是：always、everysec、no，默认的值为everysec。

　　always参数值，会使得AOF对数据的保存非常稳健。其设置意义是只要有一个写操作命令执行成功，就执行一次fsync函数调用。所以很显然always的设定值，就是三个选项值中处理效率最慢的。

　　no参数值，这个设置值表示Redis不会将执行成功的操作命令正真刷入AOF文件，而是完成操作系统级别的写操作后就认为AOF文件记录成功了，后续的I/O操作完全依赖于操作系统的设定，一般30秒会刷一次。

　　everysec参数值，这是默认的设置值，也是可以在数据稳健性和性能上平衡较好策略。它表示每秒钟都做一次fsync函数调用，正真做AOF文件的写入操作。

　　no-appendfsync-on-rewrite：always和everysec的设置会使真正的I/O操作高频度的出现，甚至会出现长时间的卡顿情况，这个问题出现在操作系统层面上，所有靠工作在操作系统之上的Redis是没法解决的。为了尽量缓解这个情况，Redis提供了这个设置项，保证在完成fsync函数调用时，不会将这段时间内发生的命令操作放入操作系统的Page Cache（这段时间Redis还在接受客户端的各种写操作命令）。

　　auto-aof-rewrite-percentage：上文说到在生产环境下，技术人员不可能随时随地使用“BGREWRITEAOF”命令去重写AOF文件。所以更多时候我们需要依靠Redis中对AOF文件的自动重写策略。Redis中对触发自动重写AOF文件的操作提供了两个设置：auto-aof-rewrite-percentage表示如果当前AOF文件的大小超过了上次重写后AOF文件的百分之多少后，就再次开始重写AOF文件。例如该参数值的默认设置值为100，意思就是如果AOF文件的大小超过上次AOF文件重写后的1倍，就启动重写操作。

　　auto-aof-rewrite-min-size：参考auto-aof-rewrite-percentage选项的介绍，auto-aof-rewrite-min-size设置项表示启动AOF文件重写操作的AOF文件最小大小。如果AOF文件大小低于这个值，则不会触发重写操作。注意，auto-aof-rewrite-percentage和auto-aof-rewrite-min-size只是用来控制Redis中自动对AOF文件进行重写的情况，如果是技术人员手动调用“BGREWRITEAOF”命令，则不受这两个限制条件左右。