Redis（六）Redis持久化之rdb和aof

一、前言

Redis提供了将内存数据持久化到硬盘，以及用持久化文件来恢复数据库数据的功能。Redis 支持两种形式的持久化，一种是RDB快照（snapshotting），默认使用此方式，另外一种是AOF（append-only-file）。 

二、RDB（RedisDataBase）

保存的文件名：dump.rdb

Redis会单独创建一个子进程来进行持久化，会将数据写到一个临时文件中，待持久化的过程都结束了，再用这个文件替换到上次持久化好的文件。整个过程主进程不需要进行任何的IO操作，这就确保了极高的性能。如果需要大规模的数据恢复，并且数据恢复的完整性不是特别敏感，那么rdb比aof的方式要更加高效。rdb的缺点是最后一次持久化的数据可能会丢失。 

 

 触发机制

1. save规则满足的情况下会自动触发rdb规则
2. 执行flushall命令，也会触发rdb规则
3. 退出Redis也会产生rdb文件

如何恢复rdb文件

一般生产环境会将改数据进行备份。

只需要将rdb文件放到redis启动目录就可以，redis启动的时候会自动检查rdb文件，恢复数据。

如何查看配置目录

config get dir

 优缺点

优点：

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

缺点：

1. 需要一定的时间间隔去操作，如果redis意外宕机了，那么最后一次修改的数据就没有了。
2. fork进程的时候，会占用一定的内存空间。

三、AOF（Append Only File）

保存的文件名：appendonly.aof

将所有的命令记录下来，恢复的时候把这个文件全部再执行一遍。

 以日志的形式来记录每个写操作，将Redis所有执行过的指令全部记录下来（读操作不记录），只允许追加文件，不可以改写文件，redis启动的时候会读取该文件重新构建数据，也就是说redis重启会根据日志文件内容将指令从前到后执行一次以完成数据的恢复工作。

默认是不开启的，我们需要手动配置，只需将appendonly改为yes就开启了aof，重启即可生效。

但是如果我们的aof文件有错误，此时redis是无法启动的。我们需要去修复该文件！

如何修复？

redis-check-aof --fix appendonly.aof #执行该命令即可修复aof文件

优缺点

优点：

1. 每次修改都同步，文件的完整性会很好
2. 每一秒都同步一次，可能会丢失这一秒钟的数据
3. 从不同步 效率最高

缺点：

1. 相对于数据文件说，aof远远大于rdb，修复速度也比rdb慢
2. aof运行效率也比rdb慢，故默认用rdb作为持久化

四、扩展

1. RDB持久化方式能够在指定时间间隔内对你的数据进行快照存储
2. AOF持久化方式记录每次对服务器写操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件的末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大
3. Redis也可以只做缓存，如果你只希望你的数据在服务器运行的时候存在，那么可以不作任何的持久化
4. 如果同时开启两种持久化方式那么redis在重启的时候会优先载入aof文件来恢复数据，因为在通常情况下，aof文件会比rdb文件要完整；RDB的数据不及时，即使同时开启也只会优先找aof文件，但不建议只单独开启aof，因为rdb更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有aof可能存在的BUG
5. 性能建议

• • 因为rdb文件只用作后备用途，建议只在Slave上持久化rdb文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则就够了
  • 如果Enable AOF，好处就是在最恶劣的情况下也只会丢失这两秒的数据，启动脚本叫简单只load自己的AOF文件就可以了，代价一是带来了持续的IO操作，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite重写的频率，AOF重写的基础大小默认是64M太小了，可以设置到5G以上，默认超过原大小100%可以改到适当数值
  • 如果不Enable AOF，仅靠Master-Slave Repllcation实现高可用性也可以，能省掉一大笔IO操作，也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时宕机（断电），会丢失十几分钟的数据！启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是用这种架构

完