RDB持久化和AOF持久化有什么优缺点？

更新时间:2021-05-07 来源:黑马程序员浏览量:

Redis 提供了两种持久化的方式，分别是RDB(Redis DataBase)和AOF(Append Only File)。

RDB，简而言之，就是在不同的时间点，将Redis 存储的数据生成快照并存储到磁盘等介质上。

AOF，则是换了一个角度来实现持久化，那就是将Redis 执行过的所有写指令记录下来，在下次Redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

RDB 和AOF 两种方式也可以同时使用，在这种情况下，如果Redis 重启的话，则会优先采用AOF 方式来进行数据恢复，这是因为AOF 方式的数据恢复完整度更高。

RDB

RDB持久化方式，是将Redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

RDB持久化方式：Redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。

对于RDB 方式，Redis 会单独创建一个子进程来进行持久化，而主进程是不会进行任何IO 操作的，这样就确保了Redis 极高的性能。

RDB优点：如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB 方式要比AOF 方式更加的高效。

RDB缺点：如果你对数据的完整性非常敏感，那么RDB 方式就不太适合你，因为即使你每5 分钟都持久化一次，当Redis 故障时，仍然会有近5 分钟的数据丢失。所以，Redis 还提供了另一种持久化方式，那就是AOF。

AOF

AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍。

实现方式：我们通过配置Redis.conf 中的appendonly yes 就可以打开AOF功能。如果有写操作(如SET 等)，Redis 就会被追加到AOF 文件的末尾。

AOF 持久化的方式：默认的AOF 持久化策略是每秒钟fsync 一次(fsync是指把缓存中的写指令记录到磁盘中)，因为在这种情况下，Redis 仍然可以保持很好的处理性能，即使Redis 故障，也只会丢失最近1 秒钟的数据。

如果在追加日志时，恰好遇到磁盘空间满或断电等情况导致日志写入不完整，也没有关系，Redis 提供了Redis-check-aof 工具，可以用来进行日志修复。

因为采用了追加方式，如果不做任何处理的话，AOF 文件会变得越来越大，为此，Redis 提供了AOF 文件重写(rewrite)机制，即当AOF 文件的大小超过所设定的阈值时，Redis 就会启动AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100 次INCR 指令，在AOF 文件中就要存储100 条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET 指令，这就是重写机制的原理。

AOF 优点：我们通过一个场景再现来说明。某同学在操作Redis 时，不小心执行了FLUSHALL，导致Redis 内存中的数据全部被清空了，这是很悲剧的事情。不过这也不是世界末日，只要Redis 配置了AOF 持久化方式，且AOF文件还没有被重写(rewrite)，我们就可以用最快的速度暂停Redis 并编辑AOF文件，将最后一行的FLUSHALL 命令删除，然后重启Redis，就可以恢复Redis的所有数据到FLUSHALL 之前的状态了。是不是很神奇，这就是AOF 持久化方式的好处之一。但是如果AOF 文件已经被重写了，那就无法通过这种方法来恢复数据了。

AOF缺点：比如在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF 方式的恢复速度也要慢于RDB 方式。

如果你直接执行BGREWRITEAOF 命令，那么Redis 会生成一个全新的AOF文件，其中便包括了可以恢复现有数据的最少的命令集。

如果运气比较差，AOF 文件出现了被写坏的情况，也不必过分担忧，Redis并不会贸然加载这个有问题的AOF 文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：

1.备份被写坏的AOF 文件。

2.运行Redis-check-aof –fix 进行修复。

3.用diff -u 来看下两个文件的差异，确认问题点。

4.重启Redis，加载修复后的AOF 文件。

1577370495235_学IT就到黑马程序员.gif