Redis进阶（详解数据持久化（备份）RDF和AOF）

聊一下Redis的持久化原理
大家都知道，Redis之所以性能好，读写快，是因为Redis是一个内存数据库，它的操作都几乎基于内存。但是内存型数据库有一个很大的弊端，就是当数据库进程崩溃或系统重启的时候，如果内存数据不保存的话，里面的数据就会丢失不见了。这样的数据库并不是一个可靠的数据库。
所以数据的持久化是内存型数据库的重中之重。它不仅提供数据保存硬盘的功能，还可以借此用硬盘容量扩展数据存储空间，使得Redis的可以存储超过机器本身内存大小的数据。

Redis对于数据持久化提供了两种持久化的方案，RDB与AOF。它们的原理和使用场景都大不相同，下面我们来详细地了解下。

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

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

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

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

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

聊聊redis持久化 – AOF
AOF，英文是Append Only File，即只允许追加不允许改写的文件。

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

我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。

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

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

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

在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性，这点大家可以放心。

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文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：

备份被写坏的AOF文件
运行redis-check-aof –fix进行修复
用diff -u来看下两个文件的差异，确认问题点
重启redis，加载修复后的AOF文件
RDB优缺点
优点

1. RDB是某一时间点的快照，是一个紧凑的单文件，更多用于数据备份。可以按每小时或每日来备份，方便从不同的版本恢复数据。
2. 单文件容易传输到远程服务做故障恢复。
3. RDB可以Fork子进程进行持久化，使Redis可以更好地处理用户请求。
4. 在大量数据的情况下，RDB相比较于AOF会更快的加载。
   缺点
5. 如果Redis不及时保存RDB文件，会造成数据的丢失。例如系统突然断电，但未来得及保存数据。即使你设置更多的Save point，也无法保证100%的数据不丢失。
6. RDB经常需要fork子进程去执行，但如果再大量数据的情况下，这个fork操作会非常耗CPU资源的。对比AOF虽然也是fork，但是它的数据保存处理是可以控制的，不需要全量保存。
   AOF优缺点
   优点
7. AOF可以设置 完全不同步、每秒同步、每次操作同，默认是每秒同步。因为AOF是操作指令的追加，所以可以频繁的大量的同步。
8. AOF文件是一个值追加日志的文件，即使服务宕机为写入完整的命令，也可以通过redis-check-aof工具修复这些问题。
9. 如果AOF文件过大，Redis会在后台自动地重写AOF文件。重写后会使AOF文件压缩到最小所需的指令集。
10. AOF文件是有序保存数据库的所有写入操作，易读，易分析。即使如果不小心误操作数据库，也很容易找出错误指令，恢复到某个数据节点。例如不小心FLUSHALL，可以非常容易恢复到执行命令之前。
    缺点
11. 相同数据量下，AOF的文件通常体积会比RDB大。因为AOF是存指令的，而RDB是所有指令的结果快照。但AOF在日志重写后会压缩一些空间。
12. 在大量写入和载入的时候，AOF的效率会比RDB低。因为大量写入，AOF会执行更多的保存命令，载入的时候也需要大量的重执行命令来得到最后的结果。RDB对此更有优势。
    参考文献
    进阶的Redis之数据持久化RDB与AOF：https://mp.weixin.qq.com/s/XuX01QRNQ9TGnS_hodCjlw

Redis入门教程：https://www.jianshu.com/p/a3915650ac3f?utm_campaign=hugo&utm_medium=reader_share&utm_content=note&utm_source=weixin-friends&from=singlemessage&isappinstalled=0

作者：哪吒小子
链接：https://www.jianshu.com/p/e4be654381e5
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。