Redis 持久化RDB 和AOF

一、持久化之全量写入：RDB

rdb配置

[redis@6381]$ more redis.conf

save 900 1

save 300 10

save 60 10000

dbfilename "dump.rdb"          #持久化文件名称

dir "/data/dbs/redis/6381"    #持久化数据文件存放的路径

上面是redis配置文件里默认的RDB持久化设置，前三行都是对触发RDB的一个条件，例如第一行的意思是每900秒钟里redis数据库有一条数据被修改则触发RDB，依次类推；只要有一条满足就会调用BGSAVE进行RDB持久化。第四行dbfilename指定了把内存里的数据库写入本地文件的名称，该文件是进行压缩后的二进制文件，通过该文件可以把数据库还原到生成该文件时数据库的状态。第五行dir指定了RDB文件存放的目录。

save 持久化命令，900 每900秒 有 1 条数据触发RDB 进行持久化保存

save 900 1

配置文件修改需要重启redis服务，我们还可以在命令行里进行配置，即时生效，服务器重启后需重新配置

而RDB持久化也分两种：

SAVE

SAVE是阻塞式的RDB持久化，当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件（即上面的dump.rdb）中，直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。

BGSAVE

BGSAVE属于非阻塞式的持久化，它会创建一个子进程专门去把内存中的数据库状态写入RDB文件里，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，这等于两个相同大小的redis进程在系统上运行，会造成内存使用率的大幅增加。

手动触发持久化命令：

bgsave save

lastsave 查看是否持久化

二、持久化之增量写入：AOF

与RDB的保存整个redis数据库状态不同，AOF是通过保存对redis服务端的写命令（如set、sadd、rpush）来记录数据库状态的，即保存你对redis数据库的写操作，以下就是AOF文件的内容

$5

15414

*3

$3

SET

$7

fsdfdf8

$8

78787878

*3

$3

SET

$3

先让我们看看如何配置AOF

dir ./　　　　　　　　　　　　　　　　#aof 文件路径

appendonly yes                       #开启AOF持久化，默认关闭

appendfilename appendonly.aof      #AOF文件名称（默认）

appendfsync always                       #AOF持久化策略

auto-aof-rewrite-percentage 100      #触发AOF文件重写的条件（默认）当前AOF文件比上次AOF重写后的文件大100%的时候进行AOF重写

auto-aof-rewrite-min-size 2mb #触发AOF文件重写的条件（默认）当AOF文件小于2mb的时候不进行AOF重写

 AOF的持久化是通过命令追加、文件写入和文件同步三个步骤实现的。

1命令追加：服务端每执行一次写操作（如set、sadd、rpush）就会把该条命令追加到一个单独的AOF缓冲区的末尾，这就是命令追加；

2文件写入：把AOF缓冲区的内容写入AOF文件里

3 文件同步：一般我们现在所使用的操作系统，为了提高文件的写入效率，都会有一个写入策略，即当你往硬盘写入数据时，操作系统不是实时的将数据写入硬盘，而是先把数据暂时的保存在一个内存缓冲区里，等到这个内存缓冲区的空间被填满或者是超过了设定的时限后才会真正的把缓冲区内的数据写入硬盘中。也就是说当redis进行到第二步文件写入的时候，从用户的角度看是已经把AOF缓冲区里的数据写入到AOF文件了，但对系统而言只不过是把AOF缓冲区的内容放到了另一个内存缓冲区里而已，之后redis还需要进行文件同步把该内存缓冲区里的数据真正写入硬盘上才算是完成了一次持久化；

appendfsync有三个选项：always、everysec和no：

1、选择always的时候服务器会在每执行一个事件就把AOF缓冲区的内容强制性的写入硬盘上的AOF文件里，可以看成你每执行一个redis写入命令就往AOF文件里记录这条命令，这保证了数据持久化的完整性，但效率是最慢的，却也是最安全的；

2、配置成everysec的话服务端每执行一次写操作（如set、sadd、rpush）也会把该条命令追加到一个单独的AOF缓冲区的末尾，并将AOF缓冲区写入AOF文件，然后每隔一秒才会进行一次文件同步把内存缓冲区里的AOF缓存数据真正写入AOF文件里，这个模式兼顾了效率的同时也保证了数据的完整性，即使在服务器宕机也只会丢失一秒内对redis数据库做的修改；

3、将appendfsync配置成no则意味redis数据库里的数据就算丢失你也可以接受，它也会把每条写命令追加到AOF缓冲区的末尾，然后写入文件，但什么时候进行文件同步真正把数据写入AOF文件里则由系统自身决定，即当内存缓冲区的空间被填满或者是超过了设定的时限后系统自动同步。这种模式下效率是最快的，但对数据来说也是最不安全的，如果redis里的数据都是从后台数据库如mysql中取出来的，属于随时可以找回或者不重要的数据，那么可以考虑设置成这种模式。

手动触发持久化AOF命令：bgrewrite

相比RDB每次持久化都会内存翻倍，AOF持久化除了在第一次启用时会新开一个子进程创建AOF文件会大幅度消耗内存外，之后的每次持久化对内存使用都很小。但AOF也有一个不可忽视的问题：AOF文件过大。你对redis数据库的每一次写操作都会让AOF文件里增加一条数据，久而久之这个文件会形成一个庞然大物。还好的是redis提出了AOF重写的机制地方地方（新连接）

最后需要注意的是，如果redis开启了AOF持久化功能，那么当redis服务重启时会优先使用AOF文件来还原数据库。