Redis学习笔记四：redis的持久化

Redis相对于memcached除了数据结构更丰富以外还有个最大的特点，就是支持数据的持久化，即把数据存储于断电后不会丢失的设备中,通常是硬盘，因此redis它是一种缓存数据库。

Redis的持久化通常有2种方式：rdb快照持久化、aof日志持久化

一、 rdb快照持久化

      快照持久化的原理即把内存里的数据当做快照，dump保存到磁盘的rdb文件中，在redis的配置文件中我们可以配置自动dump的触发规则、压缩以及rdb文件目录等

关于rdb的配置选项：

配置参数	作用
save 900 1	刷新快照到硬盘中，必须满足两者要求才会触发，即900秒之后至少1个关键字发生变化
save 300 10	必须是300秒之后至少10个关键字发生变化。
save 60 10000	必须是60秒之后至少10000个关键字发生变化。
stop-writes-on-bgsave-error yes	后台存储错误停止写。
rdbcompression ye	使用LZF压缩rdb文件。
rdbchecksum yes	存储和加载rdb文件时校验。
dbfilename dump.rdb	设置rdb文件名。
dir ./	设置工作目录，rdb文件会写入该目录。

☞  若需要手动执行rdb导出，登录redis-cli终端，执行save命令即可

☞  rdb备份的优点是它备份的是整个内存的镜像，恢复速度非常快，但缺点是在2个保存点之间,  还没没有达到rdb触发保存的条件，若此时出现断电或服务进程崩溃的情况，将会丢失1-N分钟的数据，出于对持久化的更精细要求，redis增添了aof方式 append only file

☞  若要关闭rdb导出，注释save三行即可

二、aof日志持久化

redis在2.4以后增加了aof方式 append only file日志持久化的方式，该方法类似于MySQL的bin-log，原理是将每个redis的写入动作以日志的形式存在磁盘上。

配置参数	作用
appendonly no	是否打开 aof日志功能
appendfsync always	每1个命令,都立即同步到aof. 安全,速度慢
appendfsync everysec	折衷方案,每秒写1次
appendfsync no	写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快
no-appendfsync-on-rewrite yes	正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100	aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb	aof文件,至少超过64M时,重写
appendfilename appendonly.aof	aof 储存的文件名

1、 appendfsync 设置追加aof日志的频率

      在redis里有个fsync()方法，该方法会告诉操作系统需要将redis的操作记录追加到日志文件当中，那么多久追加一次呢？ Redis默认有3中模式：no、always、everysec，

☞  no表示让操作系统自己判断缓冲区大小，然后写入aof，该方法速度较快，但是对于磁盘IO压力较大

☞  always则表示 每当redis中有写入时立即执行fsync()进行aof日志写入，该方法速度慢，但却是最安全的，如果网站并发不是很大的情况下可用此方法，鉴于以上两种模式

☞  everysec则是一个折中的方法，他表示每隔1秒向日志同步一次，这种方法如果出现宕机或服务崩溃现象，最多丢失1s的数据，配合rdb镜像则可以最大化的还原数据，该方法是Redis官方推荐的方法，也是redis的默认配置。

2、 aof重写问题

       aof记录的是我们每一次的写入记录，类似于mysql里的binlog，当我们多次写入改变某个key值得时候所有的改变操作都会被记录，然而这会导致aof文件越来越大造成磁盘空间浪费，因为在数据恢复时，我们只需知道某一个key它在最后的值是多少，并不关心它的变化过程，并且aof日志过大还会导入数据也会变得更慢，因此就有了aof重写功能，重写的作用就是使用最少的命令保存内存中的数据。比如看下面这个例子：

 

127.0.0.1:6379> set name storm1
OK
127.0.0.1:6379> set name storm2
OK
127.0.0.1:6379> set name storm3
OK

这里我们对name这个key做了3次操作，那么在aof日志中它的记录如下：

set
$4
name
$6
storm1
*3
$3
set
$4
name
$6
storm2
*3
$3
set
$4
name
$6
storm3

可以看出日志中也将操作记录了3次，但是，aof日志是数据恢复时候用的，我们其实只需要知道name这个key最后的值是什么，完全不在乎它中间的变化过程，因此当我们执行bgrewriteaof（手动执行aof重写命令）后再看看日志：

SET
$4
name
$6
storm3

重写后的aof日志一下少了很多记录。

3、 触发aof重写的规则

在redis中，配置触发aof重写规则的有两个参数： auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size

☞  auto-aof-rewrite-percentage 100    表示aof文件大小比起上次重写时的大小,增长率100%时重写aof，比如说aof日志目前有10M，当期大小变为20M时执行一次aof重写，但是当文件特别小的时候重写动作会很频繁，这时就有了auto-aof-rewrite-min-size这个配置参数，

☞  auto-aof-rewrite-min-size 64mb     该参数表示当aof文件超过某个值（默认为64M）的时候才执行重写，否则不管其大小增加了多少都不执行重写

后记：

一般情况下，我们需要同时打开两种持久化的方式来保证一旦出现意外情况丢失的数据最少，如果配置了redis集群，一般我们会在master上关闭rdb快照来减少master主机的IO读写次数，同时在其中一台slave上开启rdb即可，如果master压力不是很大，那么aof快照最好开在master主服务器上，因为主服务器的数据是最新最全的，同步到从服务器时可能有延迟而导致数据丢失，一般如果数据丢失，一般首先使用aof日志来恢复