十二：Redis持久化------RDB和AOF

RDB

持久化快照保存过程

过程：
在指定时间间隔内将内存中的数据集快照写入磁盘，也就是snapshot快照，它恢复时是将快照文件直接读到内存里。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化结束后，再用这个临时文件替换掉上次持久化好的文件。整个过程中，主进程不进行任何IO操作，这样就确保了极高的性能，如果需要进行大规模的数据恢复，且对于数据恢复程度可以有容错，则RDB方式要比AOF的效率要高，RDB的缺点就是最后一次持久化的数据可能无法恢复，我们默认的就是RDB,无需修改基本配置。
rdb保存的文件是dumb.rdb文件，都是在我们配置文件中快照中进行配置的。

测试：

触发机制：

• save规则满足情况下触发，例如以上例子：60s内修改了五次key，就会触发RDB操作
• 执行flushall操作，也会触发
• 退出Redis，也会产生rdb文件
  备份就会自动生成dumb.rdb文件
  

如何恢复RDB文件

只需要将rdb文件放在Redis启动目录下即可，Redi启动时会自动检查dumb.rdb文件，恢复其中的数据。

#查看需要存放的位置
127.0.0.1：6379>config get dir
"dir"
"usr/local/bin"#如果这个目录存在dumb.rdb文件，则启动时会自动恢复数据

小结

优点：

• 适合大规模的数据恢复
• 对数据完整性要求不高

缺点：

• 需要一定的时间间隔进行进程操作，如果Redi意外宕机了，则最后一次操作的数据则无法恢复
• fork进程的时候会占用一定的内存空间

AOF(append only file)

将所有命令都记录下来，history，恢复的时候把这个文件再执行一遍，以日志的形式来记录每个写的操作，将redis执行过的所有指令都记录起来（读操作不记录），只许追加文件，不可以修改文件，Redis启动之初会读取该文件重新构建函数，换言之，redis重启的话就会根据日志文件内容将写的指令从前到后执行一遍以完成数据的恢复工作。
aof保存的是appendonly.aof

默认是不开启的，需要我们手动开启，我们只需要将appendonly改为yes就可以开启aof，重启，Redis就生效了，
如果这个.aof文件被恶意修改，这个时候redis是无法启动的，我们需要修复这个文件，Redis为我们提供了一个修复工具：redis-check-aof --fix

如果文件正常，则启动正常。
小结

• 优点：
• 每一次修改都同步，数据完整性好
• 每秒都同步，可能会丢失这一秒的数据
• 从不同步，效率最高
• 缺点：
• 相对于数据文件来说，aof远大于rdb,修复速度不高
• AOF的运行效率慢于RDB，所以我们Redis配置默认是RDB持久化

扩展

• RDB持久化能够在指定时间间隔内对数据进行快照存储
• AOF持久化方式是记录你每次写的操作，当服务器重启的时候会重新执行这些命令来恢复原始数据，AOF以Redis协议追加每次写的操作到文件末尾，Redis还能对AOF文件进行重写，防止其文件过大。
• 只做缓存，如果希望数据在服务器运行的时候存在，可以不做持久化操作
• 若同时开启两种持久化方式，在这种情况下，Redis会优先载入AOF文件来恢复数据，因为AOF文件的数据集要比RDB文件保存的数据集要完整。RDB文件数据不实时，建议不要使用AOF，因为RDB更适合数据库备份，（AOF在不断变化不好备份），快速重启，而且不会有AOF潜在的bug.
• 性能建议：因为RDB只用作后备用途，建议只在slave上持久化RDB文件，而且只要在15分钟内备份一次就够了，只保存 save 900 1这条规则就行。
• 如果开启AOF,好处是在最恶劣的情况下丢失不会超过两秒的数据，启动脚本只要加载AOF文件即可，代价一：带来持续的IO,代价二：AOF的rewrite产生的新数据追加到文件后会带来阻塞。只要硬盘许可，AOF基础重写默认值是64M大小太小了，应该设置为5G以上。
• 如果不开启AOF，仅靠主从复制实现高可用，能省掉一大笔IO，减少了rewrite带来的波动，代价是master/slave同时宕机，则会丢失十几分钟的数据，启动脚本也要比较两个RDB文件，加载新的那一个，微博就是这种架构。