探究Redis两种持久化方式下的数据恢复

    对长期奋战在一线的后端开发人员来讲，都知道redis有两种持久化方式RDB和AOF，虽然说你们都知道这两种方式大概运做方式，但想必有实操了解得不会太多。

    这里是本身实操两种持久化方式的一点点记录。 

    先看如下摘录自redis官网原文解释(固然原文是English，这里用google翻译过了。)

Redis持久性

Redis提供了不一样的持久性选项范围：

 

RDB持久性按指定的时间间隔执行数据集的时间点快照。

AOF持久性会记录服务器接收的每一个写入操做，这些操做将在服务器启动时再次播放，以重建原始数据集。 使用与Redis协议自己相同的格式记录命令，而且仅采用追加方式。 当日志太大时，Redis能够在后台重写日志。

若是但愿，只要您的数据在服务器运行时就一直存在，则能够彻底禁用持久性。

能够在同一实例中同时合并AOF和RDB。 请注意，在这种状况下，当Redis从新启动时，AOF文件将用于重建原始数据集，由于它能够保证是最完整的。

要理解的最重要的事情是RDB与AOF持久性之间的不一样权衡。 让咱们从RDB开始：

 

RDB的优点

RDB是Redis数据的很是紧凑的单文件时间点表示。 RDB文件很是适合备份。 例如，您可能但愿在最近的24小时内每小时存档一次RDB文件，并在30天以内天天保存一次RDB快照。 这使您能够在发生灾难时轻松还原数据集的不一样版本。

RDB对于灾难恢复很是有用，它是一个紧凑的文件，能够传输到远程数据中心或Amazon S3（可能已加密）上。

RDB最大限度地提升了Redis的性能，由于Redis父进程为了持久化所须要作的惟一工做就是分叉一个孩子，其他的都将作。 父实例将永远不会执行磁盘I / O或相似操做。

与AOF相比，RDB容许大型数据集更快地重启。

 

RDB的缺点

若是您须要在Redis中止工做（例如断电后）的状况下最大程度地减小数据丢失的机会，则RDB很差。 您能够在生成RDB的位置配置不一样的保存点 （例如，在至少五分钟以后，对数据集进行100次写入，可是您能够有多个保存点）。 可是，一般会每隔五分钟或更长时间建立一次RDB快照，所以，若是Redis出于任何缘由在没有正确关闭的状况下中止工做，则应该准备丢失最新的数据分钟。

RDB须要常用fork（）才能使用子进程将其持久化在磁盘上。 若是数据集很大，Fork（）可能很耗时，而且若是数据集很大且CPU性能不佳，则可能致使Redis中止为客户端服务几毫秒甚至一秒钟。 AOF还须要fork（），但您能够调整要重写日志的频率，而无需在持久性上进行权衡。

 

AOF的优点

使用AOF Redis更加持久：您能够有不一样的fsync策略：彻底没有fsync，每秒fsync，每一个查询fsync。 使用默认策略fsync时，每秒的写入性能仍然很好（fsync是使用后台线程执行的，而且在没有进行fsync的状况下，主线程将尽力执行写入操做。）可是您只能损失一秒钟的写入时间。

AOF日志仅是一个追加日志，所以，若是断电，也不会出现寻道或损坏问题。 即便因为某种缘由（磁盘已满或其余缘由）以半写命令结束日志，redis-check-aof工具也能够轻松修复它。

Redis太大时，Redis能够在后台自动重写AOF。 重写是彻底安全的，由于Redis继续追加到旧文件时，会生成一个全新的文件，其中包含建立当前数据集所需的最少操做集，一旦准备好第二个文件，Redis会切换这两个文件并开始追加到新的那一个。

AOF以易于理解和解析的格式包含全部操做的日志。 您甚至能够轻松导出AOF文件。 例如，即便您使用FLUSHALL命令刷新了全部错误文件 ，若是在此期间未执行任何日志重写操做，您仍然能够保存数据集，只是中止服务器，删除最新命令并从新启动Redis。

 

AOF的缺点

对于相同的数据集，AOF文件一般大于等效的RDB文件。

根据确切的fsync策略，AOF可能比RDB慢。 一般，在将fsync设置为每秒的状况下，性能仍然很高，而且在禁用fsync的状况下，即便在高负载下，它也应与RDB同样快。 即便在巨大的写负载状况下，RDB仍然可以提供有关最大延迟的更多保证。

过去，咱们在特定命令中遇到过罕见的错误（例如，其中有一个涉及阻塞命令，例如BRPOPLPUSH ），致使生成的AOF在重载时没法重现彻底相同的数据集。 这些错误不多见，咱们在测试套件中进行了测试，自动建立了随机的复杂数据集，而后从新加载它们以检查一切是否正常。 可是，RDB持久性几乎是不可能的。 更明确地说：Redis AOF经过增量更新现有状态来工做，就像MySQL或MongoDB同样，而RDB快照一次又一次地建立全部内容，从概念上讲更健壮。 可是-1）应该注意的是，每次Redis重写AOF时，都会从数据集中包含的实际数据开始从头开始从新建立AOF，与始终附加AOF文件相比（或重写后的读数），对错误的抵抗力更强旧的AOF，而不是读取内存中的数据）。 2）咱们从未收到过有关真实环境中检测到的AOF损坏的用户报告。

 未完待续，今天困了，明天开始写