概述：对于内存级的KV数据库来说，将数据定时持久化到磁盘时一个必要的操作，因为一旦断电或down机，就可能导致存储在内存中的数据丢失，显然这不是我们能接受的，对于kv数据库来说，我们用得最多的无非就是memcached、TT 、etcd、redis等，而对于redis来说，相信目前已是it项目中使用最常见的缓存KV数据库了。那么它有什么策略实现数据的持久化操作呢？ 下面就一起来看看吧。
Redis有两种持久化方式，分别是RDB和AOF , 其中rdb是以间隔时间内定义key变化操作数来触发数据持久化；而oaf是以配置持久化区间来操作持久化动作。
RDB持久化：（默认持久化方式）
在指定时间间隔内，将内存中的数据集快照写入磁盘，恢复时是将快照文件直接读到内存中，来达到恢复数据的。在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。通过触发快照的形式，来做到将指定时间间隔内的数据持久化到dump.rdb。
RDB持久化的redis.conf 配置项：
save 900 1
save 300 10
save 60 1000
RDB优点与缺点：
rdb是保存一个文件，显然恢复时会方便快速，另外是触发机制类型，明显写入磁盘不会太频繁； 但缺点也很明显，在数据要求可靠性和一致性很高时，存在数据丢失的情况，原因是rdb使用的是间断性或阶段性的触发式持久化，可能会数据没持久化前故障，导致数据丢失。
AOF持久化 （默认不开启）
以日志的形式记录Redis每一个写操作,将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件不可以改写文件，redis启动之后会读取appendonly.aof文件来实现重新恢复数据，完成恢复数据的工作。默认不开启，需要将redis.conf中的appendonly no改为yes后，重新启动Redis。
AOF持久化的redis.conf 开启配置项目 ：
appendonly yes
AOF持久化策略方式：
appendfsync always:每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。
appendfsync everysec: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。
appendfsync no:不同步。
数据恢复：
重启Redis时，如果dump.rdb与appendfsync.aof同时都存在时，Redis会自动读取appendfsync.aof文件，通过该文件中对数据库的日志操作，来实现数据的恢复。当然如果该文件被破坏，我们可以通过redis-check-aof工具来修复，如redis-check-aof --fix能修复破损的appendfsync.aof文件，当然如果dump.rdb文件有破损，我们也可以用redis-check-rdb工具来修复，如果appendfsync.aof文件破损了，是启动不了客户端的，也就是无法完成数据的恢复。
AOF优点与缺点：
appendfsync always: 每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。
appendfsync everysec: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。
appendfsync no: 不同步。
appendfsync.aof文件要大于dump.rdb，如果aof同步文件持久化，会实时操作磁盘，因此会消耗一定的性能。 恢复速度方面aof会比rdb慢。
关于aof重写机制：
当AOF文件一直被追加，这就可能导致AOF文件过于庞大。因此，为了避免这种状况，Redis新增了重写机制，当AOF文件的大小超过所指定的阈值时，Redis会自动启用AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewiteaof。
触发机制：Redis会记录上一次重写时的AOF大小，默认配置是当AOF文件大小是上一次的一倍并且大于64m时，会触发从写机制。
例如配置：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
