redis持久化

redis持久化分为RDB和AOF两种方式，根据我的的理解，即一次全量的持久化和屡次增量的持久化。

一、RDB方式

RDB持久化是经过快照完成的。当符合必定条件时Redis会将内存中的全部数据生成一个副本存储在硬盘上，这个过程即为“快照”。Redis一般会在如下几种状况下会对数据进行快照：

1）根据配置进行快照

上图中的save 900 1/save 300 10/save 60 10000便是Redis的默认配置，含义是在900秒内有一个或一个以上的键值被更改则进行快照；300秒与60秒的配置相似。

2）用户执行save或bgsave命令

当执行save命令时，redis会同步进行快照操做，在执行的过程当中会阻塞全部来自客户端的请求，若是数据了过大，则执行该命令后redis将会在一段时间内无响应，故不建议在生产环境执行该命令；bgsave命令与save命令不一样，它在执行快照的过程当中仍能够处理客户端的请求，当想知道快照是否完成，能够经过lastsave命令查询最近一次完成快照的时间。

3）执行flushall命令

当执行flushall命令时，Redis会清除数据库中的因此数据，不管是否触发了自动快照的条件。当没有定义快照条件时，执行该命令不会进行快照。

4）执行复制时

这里说的复制通常指主从数据库同步数据的过程当中生成的快照，即master数据库生成快照传输给slave数据库。根据《Redis入门指南》，还有一种特殊状况，须要说明。当linux系统执行fork函数时，会采用写时复制策略，父子进程会共享同一内存数据，当父进程须要作写操做时，才会复制一份数据以保证子进程不受影响，所以，执行fork操做不会致使redis内存消耗翻倍，故须要确保linux容许应用程序申请超过可用内存（物理内存与交换分区）的空间，方法是在/etc/sysctl.conf文件中加入vm.overcommit_memory=1，而后重启系统或者执行systcl vm.overcommit_memory=1确保设置生效。

内核参数overcommit_memory 

它是 内存分配策略

可选值：0、一、2。
0， 表示内核将检查是否有足够的可用内存供应用进程使用；若是有足够的可用内存，内存申请容许；不然，内存申请失败，并把错误返回给应用进程。
1， 表示内核容许分配全部的物理内存，而无论当前的内存状态如何。
2， 表示内核容许分配超过全部物理内存和交换空间总和的内存

功能。

二、AOF

redis默认不开启AOF方式的持久化，能够修改配置appendonly yes开启。AOF文件保存位置是经过配置dir参数设置的，默认文件名是appendonly.aof，能够经过修改appendfilename参数修改。由于aof会写入每个命令操做，这会致使aof文件愈来愈大，当达到必定条件后，aof文件会进行重写（如删除被覆盖的操做记录），该配置能够在配置文件中配置：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-percentage 100参数的含义是：当当前aof文件超过上一次重写时的aof文件大小的100%时会重写；若以前没有冲写过，则以启动时的aof文件的大小为依据。

auto-aof-rewrite-min-size 64mb参数限制了容许重写的最小aof文件大小。

虽然每次更改数据库内容时，aof都会将命令写入硬盘，但实际上只是写入硬盘缓存中，默认每30s执行一次同步操做，若这期间linux系统故障则会致使硬盘缓存中的数据丢失，在Redis中能够经过设置参数来调整同步时机：

#appendsync always
appendsync everysec
#appendsync no

若是redis同时开启了RDB与AOF持久化，则Redis重启后默认以AOF恢复数据，由于AOF数据相比RDB可能会更完整些。