Redis持久性

Redis主要分为三种持久性策略：

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

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

3、AOF+RDB：混合式瞎鸡儿乱用。

RDB的优点

RDB是Redis数据的非常紧凑的单文件时间点表示。RDB文件非常适合备份。例如，您可能希望将最近24小时内的RDB文件每小时归档一次，并且每天保存30天的RDB快照。这使您可以在发生灾难时轻松恢复不同版本的数据集。

RDB非常适合灾难恢复，可以将单个紧凑文件传输到远端数据中心或Amazon S3（可能已加密）。

RDB最大限度地提高了Redis的性能，因为Redis父进程需要做的唯一工作就是坚持让一个孩子完成所有工作。父实例永远不会执行磁盘I / O或类似操作。

与AOF相比，RDB允许使用大数据集更快地重新启动。

RDB的缺点

如果你需要在Redis停止工作时（例如断电后）尽量减少数据丢失的可能性，那么RDB就不太好。你可以配置生成RDB的不同保存点（例如，至少5分钟和100次写入数据集，但可以有多个保存点）。但是，通常每五分钟或更长时间创建一次RDB快照，因此，如果Redis因任何原因停止工作而没有正确关闭，则应该为丢失最后几分钟的数据做好准备。

为了使用子进程在磁盘上保留RDB，RDB需要经常fork（）。如果数据集很大，Fork（）会很费时，并且可能导致Redis在几毫秒内停止服务客户端，或者如果数据集非常大并且CPU性能不佳，甚至会持续一秒。AOF也需要fork（），但是你可以调整你想要重写日志的频率，而不必考虑耐久性。

AOF的优势

• 使用AOF Redis更耐用：您可以拥有不同的fsync策略：从不fsync，每秒fsync，每次查询fsync。使用fsync的默认策略，每秒写入性能仍然很高（fsync使用后台线程执行，并且主线程将尽力在没有正在进行fsync时执行写入操作），但是可能丢失一秒钟的写入。

• AOF日志是一种只能追加的日志，因此如果发生停电，也不会出现查找和腐败问题。即使日志由于某种原因（磁盘已满或其他原因）以半写命令结束，redis-check-aof工具也可以轻松修复它。

• 当AOF变得太大时，Redis能够在后台自动重写。重写是完全安全的，因为在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）应该注意的是，每次AOF被Redis重写时，都会从数据集中包含的实际数据开始重新创建，与总是追加的AOF文件相比，对bug的抵抗力更强（或一个重写读取旧的AOF而不是读取内存中的数据）。（2）我们从来没有从用户那里收到关于在现实世界中发现的AOF腐败的单一报告。

快照

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

例如，如果至少有1000个key更改，则此配置将使Redis每60秒自动将数据集转储到磁盘：

save 60 1000

这种策略被称为快照。

每当Redis需要将数据集转储到磁盘时，会发生以下情况：

• Redis fork。我们现在有一个子进程和一个父进程。

• 子进程开始将数据集写入临时RDB文件。

• 当子进程写完新的RDB文件后，它会替换旧的。

此方法允许Redis受益于写入时复制语义。

日志重写

随着写操作的执行，AOF变得越来越大。例如，如果您将计数器递增100次，则最终数据集中将包含一个包含最终值的单个键，但AOF中将包含100个条目。这些条目中有99个不需要重建当前状态。

因此，Redis支持一个有趣的功能：它能够在不中断向客户端提供服务的情况下在后台重建AOF。每当您发出BGREWRITEAOF Redis时，都会编写在内存中重建当前数据集所需的最短命令序列。如果您在Redis 2.2中使用AOF，则需要不时运行BGREWRITEAOF。Redis 2.4能够自动触发日志重写（有关更多信息，请参阅2.4示例配置文件）。

可以配置Redis将在磁盘上同步数据的次数。有三种选择：

• 每当一个新命令被附加到AOF时，fsync。非常非常缓慢，非常安全。

• 每秒fsync。足够快（在2.4可能与快照一样快），并且如果发生灾难，您可能会丢失1秒的数据。

• 永远不要fsync，只需将您的数据交给操作系统即可。更快，不安全的方法。 建议的（和默认）策略是每秒fsync。它既快速又安全。

在编写AOF文件时服务器可能会崩溃，以Redis不再加载的方式破坏文件。发生这种情况时，可以使用以下步骤解决此问题：

• 制作AOF文件的备份副本

• 使用Redis附带的redis-check-aof工具修复原始文件：$ redis-check-aof –fix

• 可以使用diff -u来检查两个文件之间的区别。

• 用修复的文件重新启动服务器。

日志重写使用已用于快照的相同的写入时复制技巧。这是如何工作的：

• Redis fork，所以现在我们有子进程和一个父进程。

• 子进程开始在临时文件中写入新的AOF

• 父进程将所有新的更改累积到内存缓冲区中（但它同时将新的更改写入旧的仅追加文件中，所以如果重写失败，我们也是安全的）。

• 当子进程完成重写文件时，父进程获取信号，并在子进程生成的文件末尾追加内存缓冲区的内容。

• 现在，Redis自动将旧文件重命名为新文件，并开始将新数据附加到新文件中。

dump.rdb快照切换到AOF

需要redis版本>=2.2

redis-cli config set appendonly yesredis-cli config set save ""

第一个CONFIG命令启用仅追加文件。为了这样做，Redis将阻止生成初始转储，然后将打开该文件进行写入，并将开始附加所有下一个写入查询。

第二个CONFIG命令用于关闭快照持久性。这是可选的，如果你希望你可以同时启用两个持久化方法。

重要提示：请记住编辑redis.conf以打开AOF，否则当您重新启动服务器时，配置更改将丢失，服务器将以旧配置重新启动。

AOF和RDB持久性之间的交互

Redis> = 2.4确保避免在RDB快照操作正在进行时触发AOF重写，或在AOF重写过程中允许BGSAVE。这可以防止两个Redis后台进程同时执行繁重的磁盘I / O操作。

在进行快照并且用户使用BGREWRITEAOF明确请求日志重写操作时，服务器将回复一个OK状态代码，告诉用户操作已安排，并且一旦快照完成，重写将开始。

在启用AOF和RDB持久性并且Redis重新启动的情况下，AOF文件将用于重建原始数据集，因为它保证是最完整的。

备份Redis

可以在数据库运行时复制RDB文件，RDB一旦生成就不会被修改，并且在生成时它会使用临时名称并仅在新快照完成时使用rename（2）以原子方式重命名为其最终目标。

这意味着在服务器运行时复制RDB文件是完全安全的。可以采取以下做法：

• 在您的服务器中创建一个cron作业，在一个目录中创建RDB文件的每小时快照，并在不同的目录中创建每日快照。

• 每次运行cron脚本时，都要确保调用find命令以确保删除过旧的快照：例如，您可以在最近的48小时内进行每小时快照，并且每日快照可以持续一个或两个月。确保使用数据和时间信息命名快照。

• 每天至少一次确保在数据中心之外或至少在运行Redis实例的物理机之外传输RDB快照。

灾难恢复

Redis上下文中的灾难恢复基本上与备份相同，并且可以在许多不同的外部数据中心中传输这些备份。这样，即使在某些灾难事件影响Redis正在运行的主数据中心并正在产生其快照的情况下，数据也可以得到保护。

• Amazon S3和其他类似的服务是安装灾难恢复系统的好方法。只需将您的每日或每小时RDB快照以加密形式转移到S3即可。您可以使用gpg -c（在对称加密模式下）加密数据。确保将密码存储在许多不同的安全地点（例如，将副本复印给组织中最重要的人员）。建议使用多种存储服务以提高数据安全性。

• 使用SCP（SSH的一部分）将您的快照传输到远端服务器。这是一个相当简单和安全的路线：在距离你很远的地方获得一个小型VPS，在那里安装ssh，然后生成一个没有密码的ssh客户端密钥，然后将其添加到小型VPS的authorized_keys文件中。您已准备好以自动方式传输备份。在两个不同的提供商中获得至少两个VPS以获得最佳结果。

官方API文档：https://redis.io/topics/persistence