redis作为一个内存数据库 高QPS每秒查询率(Query Per Second) 是它的特点。
它的数据持久化有两种策略。
1、RDB
2、AOF

RDB的特性如下：

fork一个进程，遍历hash table，利用copy on write，把整个db dump保存下来。
save, shutdown, slave 命令会触发这个操作。
粒度比较大，如果save, shutdown, slave 之前crash了，则中间的操作没办法恢复。

AOF有如下特性：

把写操作指令，持续的写到一个类似日志文件里。（类似于从postgresql等数据库导出sql一样，只记录写操作）
粒度较小，crash之后，只有crash之前没有来得及做日志的操作没办法恢复。

具体配置：

在redis.conf的配置文件中,应当视需求适当配置redis

RDB的配置相关

################################ SNAPSHOTTING  ################################
1、save指令触发的条件
save 900 1           #15分钟有一个key修改就触发save
save 300 10         #5分钟有十个key修改就触发save
save 60 10000     #1分钟有一万个key修改就触发save

2、stop-writes-on-bgsave-error yes/no （默认值为yes）
即当bgsave快照操作出错时停止写数据到磁盘，这样后面写错做均会失败，为了不影响后续写操作，故需将该项值改为no 

3、rdbcompression yes/no  
指定存储至本地数据库时是否压缩数据，默认是yes，redis采用LZF压缩，如果为了节省CPU时间可以改成no 但会导致数据库文件扁的巨大

4、rdbchecksum yes/no
对rdb数据进行校验,耗费CPU资源,默认为yes

5、dbfilename dump.rdb
备份文件名称

6、dir ./
备份文件存放的地址

AOF 配置相关

############################## APPEND ONLY MODE ###############################

1、appendonly yes/no
是否开启AOF的持久化方式

2、appendfilename "appendonly.aof"
备份文件的名称

3、备份规则
appendfsync always #每次写一条记录都会备份到日志中写道磁盘上。性能会降低很多 但是可以确保记录不丢失
appendfsync everysec #每一秒钟将OS cache中的数据fsync到磁盘上。性能比较好。建议使用的规则
appendfsync no #只把数据写道os cache ，与操作系统来决定什么时候同步到磁盘。性能最高。但是不确定什么时候持久化大磁盘。不可控。

4、no-appendfsync-on-rewrite yes/no 一般为了保证数据完整不丢失都会设置为no

因为服务器的内存有限，redis可以存放的数据也是有限的。有些数据可能会自动过期 或者别操作删除掉，
但是写日志并没有被清理掉。导致这些数据会被恢复或者aof的文件会越来越大。
redis为了处理这个问题会每隔一段时间在后台基于当前redis中的数据重新写一次aof日志文件，覆盖之前的文件。
rewritef操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。
如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在linux的操作系统的默认设置下，最多会丢失30s的数据。


5、auto-aof-rewrite-percentage 100
aof文件增长比例，指当前aof文件比上次重写的增长比例大小。aof重写即在aof文件在一定大小之后，重新将整个内存写到aof文件当中，。这样就避免了，aof文件过大而实际内存数据小的问题(频繁修改数据问题).

6、auto-aof-rewrite-min-size 64mb
aof文件重写最小的文件大小，即最开始aof文件必须要达到这个文件大小时才触发，后面的每次重写就不会根据这个变量了(根据上一次重写完成之后的大小).此变量仅初始化启动redis有效.如果是redis恢复时，则lastSize等于初始aof文件大小.


7、aof-load-truncated yes/no
指redis在恢复时，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能存在指令写错的问题(突然断电，写了一半)，这种情况下，yes会log并继续，而no会直接恢复失败.

如果 RDB 和AOF 同时工作

1.如果RDB在执行snapshotting操作，那AOF不会rewrite。如果AOF不会rewrite，那RDB不会进行snapshotting操作。
2.RDB在执行snapshotting操作，如果用户执行了rewrite aof的命令， 那redis会在RDB执行完成后在执行rewrite。
3.如果有RDB snapshot文件 和AOF 日志同时存在，redis在恢复数据的时候默认使用aof，因为日志更完整。

如果AOF的文件受损了

执行 redis-check-aof --fix 来修复受损的aof文件