细说Redis持久化机制

概述

Redis不仅能够作为缓存来使用，也能够作为内存数据库。

Redis作为内存数据库使用时。必需要解决一个问题：数据的持久性。有些将Redis作为缓存使用的场景也需要将缓存的数据持久化到存储介质上，这样在Redis重新启动后仍然能对热点数据提供缓存服务。不会由于缓存数据的缺失而对整个系统造成冲击。

本文就Redis内置的持久化机制进行说明。

Redis持久化方式

Redis内置的持久化方式有两种：快照方式和AOF方式。

快照方式是将某一时点的内存数据写到硬盘上。AOF方式是将写入的命令记录在硬盘上的文件中。以下具体说明这两种方式。

快照方式

快照方式能够将一个时点的内存数据保存到硬盘。保存快照之后Redis重新启动时能够读取快照文件而恢复数据，也能够使用快照来建立复制相应的Redisserver。

快照持久化模式

既然快照是保存某一个时点的内存数据，那么就要求在进行快照时内存数据不能发生变化。关于这点Redis有两种模式：SAVE和BGSAVE。SAVE模式首先使Redis停止服务，然后将这个时点的Redis内存数据写入到硬盘中。等完毕写入后Redis開始提供服务，这个过程通常会比較长，在生产环境中使用的场景较少。

BGSAVE模式会使用fork命令拷贝Redis的内存，在fork过程中Redis也会停止对外服务，但这个过程很快。在实体机或者VMWare和KVM中1G的内存拷贝大概在10-20ms，而在Xen中要稍慢些，大概在200-300ms。

拷贝内存完毕后，拷贝的这份内存数据開始持久化到硬盘。同一时候Redis也继续对外提供服务。

SAVE模式对Redis可用性影响非常大。可能使Redis在一段较长时间内无法提供服务。BGSAVE模式对Redis可用性影响较小，1G的内存数据会使Redis中断服务10-20ms。这个数值在普通情况下是能够接受的，可是由于BGSAVE是使用fork机制，这就要求fork时系统的可用内存至少要和Redis占用的内存一样大。

快照的触发条件

触发Redis进行内存快照持久的条件有下面几种：

给Redisserver发送BGSAVE命令，这将触发Redis进行BGSAVE模式的快照持久。

给Redisserver发送SAVE命令。这将触发Redis进行SAVE模式的快照持久。
Redis接收到SHUTDOWN命令或者TERM信号，将触发Redis进行SAVE模式的快照持久。之后Redis停止。
在主从结构中。当从Redis同步主Redis时间太长时。主Redis会触发BGSAVE模式的快照持久。

在配置文件的save属性中配置Redis在某个条件满足时进行持久，这会触发Redis进行BGSAVE模式的持久。比如，在配置文件里配置`save 60 10000`。意为假设在60s内发生了10000次写操作那么Redis将启动BGSAVE操作。在配置文件里能够配置多个save，当有一个save条件满足时。Redis就运行BGSAVE操作。

快照配置的參数

參数名称	參数值	參数解释
save	m秒 n次，比方60 1000	配置触发快照的条件。"60 1000"表示假设在60s内发生了1000次写操作。那么Redis就要进行持久操作
stop-writes-no-bgsave-error	yes,no	配置在BGSAVE错误发生时是否停止
rdbcompression	yes,no	配置是否对持久数据进行压缩
dir	文件夹路径，比方./	配置持久文件保存的文件夹
dbfilename	持久文件名称。比方dump.rdb	配置持久文件名称

快照存在的问题

从上面的说明能够看出，快照持久化方式是基于时间点的，假设在一次快照完毕，下一次快照还没開始之前Redis崩溃了，那么上一快照之后的数据变化将会丢失。

在BGSAVE模式下，假设在快照刚结束时Redis崩溃，那将会丢失内存拷贝之后的发生变化的数据。

AOF方式

AOF方式将Redis每次的写操作都保存在日志文件里。通过回放日志文件Redis就可以恢复全部的数据。Redis将每次写操作的日志都保存在内存的一个缓存区中而不是即时写入硬盘，Redis提供了三种方式将内存日志同步到硬盘。

文件同步方式

always : Redis在每次有写操作发生时都会同步到硬盘，这样的方式会给IO带来非常大压力，实际中写入的速率要考虑硬盘的IO速率。
everysec :Redis每1秒将日志同步到硬盘。这样的方式性能较好，但也意为着假设Redis崩溃那么将丢失1秒的数据。

no : Redis不主动控制内存缓存区和硬盘的同步，而由操作系统来控制。

这样的方式不可控，一般不採用。

Rewriting/compacting AOF

AOF方式各方面比較均衡。可是有个缺点：随着Redis的执行硬盘上的日志文件将会越来越大，将会占用大量硬盘空间，并且在Redis重新启动时也会由于日志文件太大而须要非常长的启动时间。

为了解决问题Redis提供了BGREWRITEAOF命令来重建日志。

BGREWRITEAOF执行机制

BGREWRITEAOF执行机制和BGSAVE非常类似：使用fork创建拷贝进程，然后再将拷贝内存中的数据写入到暂时的日志文件里。完毕写入后再用rename原子操作替换掉日志文件。

BGREWRITEAOF存在的问题

BGREWRITEAOF同BGSAVE一样有着下面问题：

fork时要暂停Redis对外服务
须要系统为fork保留内存空间

除此之外，BGREWRITEAOF还有这自己的问题：

由于要替换日志文件，假设日志文件很大。比方几十G，那么替换日志文件的时间也会比較长。

[title3]

AOF配置的參数

[/title3]

參数名称	參数值	參数解释
appendonly	yes,no	配置是否开启AOF持久机制
appendfsync	always,everysec,no	配置AOF持久机制的同步策略
no-appendfsync-on-rewirte	yes,no	配置在重建日志时是否继续进行AOF
auto-aof-rewrite-percentage	百分比值 比方100	配置触发重建日志的条件：当前日志大小和最后一次重建日志大小的比例，这里的"100"意为当前日志大小超过最后一次重建日志大小100%时。将可能触发重建日志操作。
auto-aof-rewrite-min-size	日志文件大小 比方64mb	配置触发重建日志的条件：当前日志大小的最小值，这里的"64mb"意为当前日志超过64mb时，将可能触发重建日志操作。 要注意的是：auto-aof-rewrite-percentage和auto-aof-rewrite-min-size必须同一时候满足才干够触发重建日志操作。
dir	文件夹路径 比方./	配置持久文件保存的文件夹

持久化方式比較

分析了Redis的快照和AOF持久机制，在实际生产环境中部署该选择哪种方式呢？以下从Redis可用性影响、数据丢失、内存占用、IO负荷、硬盘空间占用几个维度比較各持久化方式：

持久化方式	可用性影响	数据丢失	内存占用	IO负荷	硬盘空间占用
SAVE	高	分钟级	小	高	较低
BGSAVE	较小	分钟级	大	高	较低
AOF	小	秒级	小	较高	高
AOF+BGREWRITEAOF	较小	秒级	大	最高	较高

从上表能够看出AOF或者AOF+BGREWRITEAOF方式在一般场景下应该是优先考虑的持久化方式。