Redis两类持续性的方法
-
RDB方案可以在规定时间间隔内创建数据集的时间点快照。 -
AOF方案记录了服务器执行的所有写操作命令，并在服务器启动时通过重新执行这些命令来还原数据集。AOF文件完全遵循Redis协议格式保存，新命令会被追加到文件末尾。此外，Redis还能在后台对AOF文件重写以确保不超过实际需要的文件大小。 -
Redis还可同时使用AOF和RDB持续性方法。在这种情况下，Redis重启时将优先使用AOF文件还原数据集，因为AOF文件所保存数据通常比RDB文件完整。
RDB的优势
-
RDB是一个非常紧凑的文件，保存了Redis在某一时间点上的数据集。此特点使得RDB文件非常适合备份用途。比如，可以每小时备份一次RDB文件，在每天备份一次，以便在问题发生时可以恢复到不同版本的数据集。 -
RDB非常适合用于灾难恢复。它只有一个文件且内容紧凑，可以加密后传输到其他数据中心或亚马逊S3中。 -
RDB可以最大化Redis的性能。父进程在保存RDB文件时只需要fork出一个子进程，然后子进程负责处理所有保存工作，父进程无需执行任何磁盘I/O操作。 -
RDB在恢复大数据集时速度比AOF快。
RDB的劣势
-
如果需要最小化数据丢失风险，RDB不适合。虽然Redis允许设置不同的保存点来控制保存RDB文件的频率，但由于RDB文件需要保存整个数据集状态，所以并非轻松操作。因此，可能需要至少5分钟才能保存一次RDB文件。在这种情况下，一旦发生故障停机，可能会丢失几分钟的数据。 -
每次保存RDB时，Redis都要fork()一个子进程来进行实际持久化工作。对于大型数据集，fork()可能耗时较长，导致服务器在某些毫秒内停止处理客户端。如果数据集特别大且CPU时间紧张，这种停机时间甚至可能长达一秒钟。尽管AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的耐久性都不会有损失。
AOF的优势
-
使用AOF持久化可以极大地提高Redis的持久性。可以设置不同的fsync策略，例如无fsync、每秒一次fsync或每次写入命令时fsync。默认策略为每秒一次fsync，在此配置下，Redis仍然能够保持良好性能，即使发生故障停机，最多只会丢失一秒钟的数据（fsync在后台线程执行，所以主线程可以继续处理命令请求）。 -
AOF文件是一个只进行追加操作的日志文件，因此写入AOF文件不需要seek操作。即使日志中包含未完整写入的命令（如写入时磁盘已满，写入中断等），redis-check-aof工具也可以轻松修复此类问题。 -
当AOF文件体积变大时，Redis可以自动在后台对AOF重写。重写后的新AOF文件仅包含恢复当前数据集所需的最小命令集合。整个重写过程是安全的，因为Redis在创建新AOF文件时会继续将命令追加到现有的AOF文件中，即使在重写过程中发生故障停机，现有的AOF文件也不会丢失。一旦新AOF文件创建完成，Redis会从旧的AOF文件切换到新的AOF文件，并开始追加操作。 -
AOF文件以有序的方式保存对数据库执行的所有写入操作，这些操作以Redis协议格式保存，使得AOF文件内容容易阅读和解析。导出AOF文件也很简单，举个例子，如果不小心执行了FLUSHALL命令，只要停止服务器，移除AOF文件末尾的FLUSHALL命令，并重启Redis，就可以将数据集恢复到FLUSHALL执行之前的状态。
AOF的劣势
-
对于相同的数据集来说，AOF文件的体积通常比RDB文件的体积大。 -
根据所使用的fsync策略，AOF的速度可能会慢于RDB。一般情况下，每秒一次fsync的性能依然很高，关闭fsync可以使AOF与RDB具有相同的速度，即使在高负载下也如此。但在处理大量写入负载时，RDB可以提供更可靠的最大延迟时间。 -
AOF曾经发生过一些bug，导致在重新加载AOF文件时无法恢复到保存时的原样。这种bug并不常见，并且测试套件已添加了测试以确保恢复功能正常。虽然AOF的这些bug不太常见，但与RDB相比，几乎不可能出现这种问题。
本文由 mdnice 多平台发布
