一：什么是redis持久化 :Redis工作时数据都存储在内存中，万一服务器断电，则所有数据都会丢失。针对这种情况，Redis采用持久化机制来增强数据安全性。，持久化技术分为RDB和AOF，下面我将分别介绍这两种机制.
二：关于RDB(Redis DataBase)
1.什么是RDB: 简而言之，就是在不同的时间点，将redis存储的数据生成SNAPSHOTTING并存储到磁盘上；
2.RDB机制原理: Redis会单独创建(Fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能,如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
3.RDB的触发时机:
# save "" 禁用RDB持久化的策略，只要不设置任何save指令，或者给
save传入一个空字符串参数也可以.
sava 秒钟 写操作次数
save 900 1 900s内至少修改1个key会触发RDB
save 300 10 300s内至少修改了10个key会触发RDB
save 60 10000 60s内至少修改了10000次的key会触发RDB
案例演示，将save 300 10改为save 60 5 并将dump.rdb文件先删除掉 观察效果
这里可以看到当我们键修改大于5次时,dump.rdb文件重新生成.
这是我们关闭redis后在重新打开看dump.rdb发现已经将我们之前的数据重新加载到memory中,
4.如何触发RDB快照 ：
1.配置文件中默认的快照配置
拷贝后重新使用 cp dump.rdb dump.rdb_bk
2.save或者是bgsave命令
save和bgsave一般应用在事件比较紧急的情况下,也就是改动了键值立马保存在dump.rdb中。
3.执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。
5.RDB的优势和劣势
优势:
1.适合大规模的数据恢复
2.对数据完整性和一致性要求不高
劣势:
1.在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一
次快照后的所有修改。
2.Fork的时候，内存中的数据被克隆了一份，大约2倍的膨胀性需要考虑。
三：关于AOF(Append Only File)
1.什么是AOF:
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作。
注意默认情况下redis.conf中aof功能是关闭的,我们需要手动的打开
2.AOF中数据的恢复形式(此操作前我么可以先把dump.rdb这个文件暂时先删掉,然后复制一份名字叫做redis.conf_aof的文件在当前目录下)
随着我们更改后几个键值可以发现appendonly.aof和dump.rdb这两个文件已经分别生成.
3.目录中同时存在appendonly.aof和dump.rdb时appendonly.aof的文件优先级高,例如我们可以在上述的appendonly.aof文件中添加一些错误文本内容(最后一行即是我们乱写的内容),对于dump.rdb这个正确的文件我们并不改变它.
当我们重启redis时,发现出现错误,所以此时可以判定当这两个文件同时处出现时,appendonly.aof的优先级要高,
此时redis还提供给我们一个修复损坏的appendonly.aof文件的一个方法，./redis-check-aof --fix ../appendonly.aof ，出现Successfully则代表修复成功.,然后再次重启redis的时候边可以正常启动了,并且之前的数据也可以加载到memory中.
4.关于AOF中几个重要的参数
1 appendonly no 默认是mo，一般我们要用AOF时要将no改为yes
2 appendfilename "appendonly.aof" 生成的AOF的文件名,一般情况下不要去修改这个名字
3 Appendfsync everysec (其他两个值分别是Always和no)
Always：同步持久化，每次发生数据变更会立即记录到磁盘，性能较差但数据完整性比较好
Everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失(此参数用的较多)
no ：从不同步
5.关于AOF中的Rewrite:
5.1 rewrite:
AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，
新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
可以使用命令gbrewriteaof
5.2 rewriet重写原理:
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后在rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
5.3 rewrite触发机制:
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
6.AOF的优势和劣势
优势:见上述4.3
劣势:相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
AOF运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。
四: RDB和AOF两者到底该用哪一个？
建议是同时开启这两种持久化方式,因为在这种情况下
1.当redis重启时会优先载入AOF来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
2.RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,但是此时RDB也需要存在,因为RDB更适合于备份数据库(AOF在不断的变化不好备份)，快速重启,而且不会有AOF可能潜在的BUG,留着可以作为一个数据恢复的手段.