RDB
①在指定的时间间隔内将内存中的数据集快照写入磁盘（Snapshot快照），恢复是将快照文件直接读到内存里
②快照文件dump.rdb；
②save 30 10：改的key越多，持久化间隔越短（设为30秒内10个k变动就进行持久化，如果30秒内有12个，则会在10个时进行持久化，然后重新计时）
②Save／bgSave：手动／自动持久化，手动会阻塞进行持久化，自动会后台异步快照，同时也能响应请求
③除了快照存储位置和保存间隔，其它配置都推荐使用默认的配置
④快照流程：创建fork子进程，子进程创建临时文件，写入要持久化的内容，再替换dump.rdb，整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
⑤如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失（没到保存快照的时间时redis崩溃了，则这个间隔的时间内数据就丢失了）。
⑥fork的时候，内存中的数据被克隆了一份，大致2倍的嘭胀性需要考虑
AOF
①以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
②默认不开启，appendonly yes开启，与RDB同时开启，以AOF优先
③如AOF文件损坏，通过/usr/local/bin/下 redis-check-aof --fix appendonly.aof进行恢复
④同步频率设置：appendfsync always/everysec/no：总是／每秒／不同步
⑤Rewrite压缩：只关注最终结果，即原先执行多条操作，最后重写压缩成一个操作；如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。
⑥官方推荐两个都启用，但如果对数据不敏感，可以选单独用RDB，不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。
