Redis的持久化RDB与AOF

Redis的持久化

---

redi提供了不同范围的持久化选项

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

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

3：你不想持久化，可以直接禁用持久化

4:可以在同一实例中同时合并AOF和RDB。
请注意，在这种情况下，当Redis重新启动时，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优势

• 使用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损坏的用户报告。

怎么使用备份呢？

• 1.RDB快照备份:

  • 默认情况下，Redis将数据集的快照保存在磁盘上名为的二进制文件中dump.rdb。您可以配置Redis，使其在数据集中至少有M个更改时每N秒保存一次数据集，也可以手动调用SAVE或BGSAVE命令。

    save 60 1000:如果更改了至少1000个键，此配置将使Redis每60秒自动将数据集转储到磁盘上

• 2.AOF追加日志备份：

  • 快照不是很持久。如果运行Redis的计算机停止运行，电源线出现故障或kill -9实例意外运行，则写入Redis的最新数据将丢失。尽管这对于某些应用程序可能不是什么大问题，但有些使用案例具有充分的耐用性，在这些情况下，Redis并不是可行的选择。
  • 该只追加文件是Redis的选择，完全耐用的策略
  • appendonly yes:每次Redis收到更改数据集的命令（例如SET）时，它将添加到AOF。重新启动Redis时，它将重新播放AOF以重建状态。
  • 配置Redis将fsync磁盘上的数据进行多少次
    • appendfsync always：fsync每次将新命令附加到AOF时。非常非常慢，非常安全。
    • appendfsync everysec：fsync每秒。速度足够快（在2.4中可能与快照速度一样快），如果发生灾难，您可能会丢失1秒的数据。
    • appendfsync no：从不fsync，只需将数据交给操作系统即可。更快，更不安全的方法。通常，Linux使用此配置每30秒刷新一次数据，但这取决于内核的精确调整。

  建议（默认）策略是fsync每秒执行一次。它既快速又安全。该always策略在实践中非常慢，但是它支持组提交，因此，如果有多个并行写入，Redis将尝试执行单个fsync操作。

    redis文档：https://redis.io/topics/persistence