RDB
??原理
????Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中（在指定目录下生成一个dump.rdb文件）
??优点
????a.方便备份，适合大规模的数据恢复
????b.性能好
????c.启动效率高
??缺点
????a.数据的完整性和一致性不高（最后一次备份前发生故障，那么上一次备份至故障的这段时间内的变更都会丢失）
????b.备份时会占用内存，当数据集比较大时，会占用较长的CPU，可能会导致redis停止服务几百ms，甚至1s
??恢复
????Redis重启会通过加载dump.rdb文件恢复数据
??压缩
????Redis采用LZF压缩方式，但会占用了一点CPU的时间，默认开启，也推荐开启，不然会导致数据库文件变的巨大
AOF
??原理
????Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中
??优点
????a.数据的完整性和一致性高
????b.数据安全，即使append时中途宕机也不会破坏已有的内容
??缺点
????a.性能没rdb那么好
????b.文件会越来越大，恢复会越来越慢
??恢复
????Redis重启时会根据日志文件的内容将写指令从前到后执行一次完成数据恢复
??持久化策略
????同步至磁盘，有三种可选策略：
??????a.always 每次数据发生变化都会立刻写入磁盘
??????b.everysec 默认，每秒异步写入磁盘一次(这秒变更的数据)
??????c.no 不同步至磁盘
??压缩——rewrite重写
????由于aof文件会越来越大，所以提供了一种缩小aof文件方法——重写。
????Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中，最后替换旧的aof文件（这里旧文件都很大了，所以并不会读取旧文件，只需要写入现在redis存在的数据即可）
最后方案推荐
????1.Redis的持久化和数据的恢复选择在夜深人静的时候比较好
????2.若考虑了Redis持久化，那么RDB（默认开启）和AOF（需要手动开启）都建议开启，AOF出问题，还有RDB（RDB也更适合恢复和备份）
注：本文基本借鉴于ITDragon龙-Redis 持久化之RDB和AOF，里面还有更详细的操作
|