RDB及其优劣势
rdb概述：在指定的时间间隔内将内存中的数据集快照写入磁盘。
详细说明：Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再将这个临时文件替换上次持久化好的文件。
产生快照的过程
1.执行save命令（save时只管保存，其他不管，全部阻塞）
2.执行bgsave命令（Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间）
3.redis.conf中的默认设置
save 900 1 //900s内有一次更改
save 300 10 //300s内有10次更改
save 60 10000 //60s内有10000次更改
save " " //禁用rdb
4.用户发送shutdown命令
优势
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高
劣势
- 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
- Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
AOF及其优劣势
aof：以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
aof之rewrite
概念：aof采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当aof文件的大小超过所设定的阈值时，redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。
原理：aof文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
触发机制：redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64m时触发。
优势
- 每秒同步：appendfsync always --- 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性较好。
- 每修改同步：appendfsync everysec --- 异步操作，每秒记录，如果一秒内宕机，会有数据丢失。
- 不同步：appendfsync no --- 从不同步
劣势
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。
顺便记录一下redis的缓存过期策略
有6种选择（LRU：最近最少使用）
volatile-lru：使用LRU算法移除key，只对设置了过期时间的key
allkeys-lru：使用LRU算法移除key，作用对象为所有key
volatile-random：在过期集合中随机移除key，只对设置了过期时间的key
allkeys-random：随机移除key，作用对象为所有key
volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
noeviction：不进行移除。针对写操作，只是返回错误信息