思维草图
redis持久化认识
Redis是一个基于内存的数据库，它的数据是存放在内存中，内存有个问题就是关闭服务或者断电会丢失。
Redis的数据也支持写到硬盘中，这个过程就叫做持久化。
Redis提供了2种不同形式的持久化方式。
- RDB（Redis DataBase）
- AOP（Append Of File）
RDB（Redis DataBase）
在指定的时间间隔内将内存中的数据集快照写入磁盘，即Snapshot快照，它恢复时是将快照文件直接读到内存里。
特征
- redis会单独创建（fork）一个子进程进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束后，再用这个临时文件替换上次持久化好的文件。
- 整个过程中，主进程是不进行任何IO操作的，确保了极高的性能。
- 如果需要进行大规模的恢复，且对数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
- RDB的缺点是最后一次持久化后的数据可能丢失。
配置
打开redis.conf文件
备份与恢复
备份
将rdb的备份文件 *.rdb 文件拷贝到别的地方
cp dump.rdb dump2.rdb恢复
- 关闭redis
- 把备份的文件拷贝到工作目录 cp dump2.rdb dump.rdb
- 启动redis，备份数据直接加载，数据被恢复
优势与劣势
优势
- 适合大规模数据恢复
- 对数据完整性和一致性要求不高
- 节省磁盘空间，恢复速度快
劣势
- Fork的时候，内存中的数据会被克隆一份，大致2倍的膨胀
- 虽然Redis在fork的时候使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能
- 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down的话，就会丢失最后一次快照后所有修改
AOF（Append Only File）
以日志的形式来记录每个写操作（增量保存），将redis执行过的所有写指令记录下来（读操作不记 录），只允追加文件但不可改写文件，redis启动之初会读取该文件重新构造数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。AOF默认不开启。
特征
- 客户端的请求写命令会被append追加到AOF缓冲区内
- AOF缓冲区会根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
- AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写（rewrite），压缩AOF文件容量
- redis服务器重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的
配置
内容和rdb的大同小异
AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）。
备份与恢复
备份和恢复的操作同RDB一样，都是拷贝备份文件， 需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
但是AOF会有有两种情况
正常恢复
- 修改默认的appendonly no，改为yes
- 将有数据的aof文件复制一份保存到对应的目录（查看目录：config get dir）
- 重启redis然后重新加载
异常恢复
- 修改默认的appendonly no，改为yes
- 遇到aof文件损坏，通过 /usr/local/bin/redis-check-aof --fix appendonly.aof 进行 恢复
优势与劣势
优势
- 备份机制更稳健，丢失数据概率更低
- 可读的日志文本，通过操作AOF文件，可以处理误操作
劣势
- 比RDB占用更多的磁盘空间
- 恢复备份速度要慢
- 每次读写都同步的话，有一定的性能压力
- 存在个别bug，造成不能恢复
总结
用哪个好？
官方推荐2个都启用。
- 如果对数据不敏感，可以单独用RDB。
- 不建议单独使用AOF，因为可能会出现BUG。
- 如果只是做纯内存缓存，可以都不用。
