Redis 的 持久化机制(AOF\RDB)

Redis 作为一款高性能的内存数据库，其数据存储在内存中，为了防止服务器宕机或故障导致数据丢失，需要采用持久化机制将数据保存到磁盘。AOF（Append Only File，仅追加文件）和RDB（Redis Database Backup）就是 Redis 重要的持久化方式。

AOF原理

AOF 持久化通过保存 Redis 执行的写命令来记录数据库的状态。它将所有的写操作（如 SET、DEL 等）以日志的形式追加到 AOF 文件中，而读操作不进行记录。在 Redis 重启时，会读取 AOF 文件并重新执行其中的写命令，从而恢复数据库的状态。

AOF 持久化策略

Redis 为 AOF 提供了三种写磁盘的策略：

• Always（每条指令保存一次）：每执行一个写命令，Redis 都会立即将其同步写入磁盘，然后才返回结果给客户端。这种策略保证了数据的即时性，但在磁盘 I/O 繁忙时会阻塞 Redis 主线程，增加响应延迟。若在写入磁盘过程中出现断电或宕机，且内存写入成功，Redis 重启后通过 AOF 文件恢复数据时，可能无法恢复正在执行的这条数据。

• EverySecond（每秒钟保存一次）：Redis 执行写操作后先写入内存和 AOF 缓冲区，然后立即返回结果，后台线程每秒将缓冲区内容写入磁盘。这种策略在断电或宕机时可能丢失最近一秒的数据。

• No（不保存）：Redis 写入内存成功后将写命令写入 AOF 缓冲区，至于缓冲区何时写入磁盘由操作系统决定。在这种策略下，断电或宕机时丢失的数据量由操作系统的刷盘机制决定。

AOF 持久化流程

当客户端发送写命令请求时，首先会被追加到 AOF 缓冲区。接着，根据设定的持久化策略（如 always、everysec 或 no），将缓冲区中的操作同步到磁盘的 AOF 文件中。

如果 AOF 文件大小超过了重写策略设定的值或者进行手动重写，Redis 会对 AOF 文件进行重写，以压缩文件容量。当 Redis 服务重启时，会重新加载 AOF 文件中的写操作，实现数据恢复。

AOF 文件的重写

随着时间推移，AOF 文件会因保存的写命令增多而体积增大，Redis 重启时恢复数据的时间也会变长。因此，需要对 AOF 文件进行重写以瘦身。

AOF 重写并非读取和修改原文件，而是针对数据库中键的当前值，用最少的命令来替代之前的多条命令。例如，对于对某个键的多次操作，可以用一条能恢复当前值的命令替代之前的多条命令。

Redis 在 4.0 版本后的重写，是将 RDB 的快照以二进制形式附在新的 AOF 头部，作为历史数据，替换原有的流水账操作。

重写过程中，主线程会 fork 出一个子进程来执行重写操作。这样做有两个好处：一是主进程可以继续处理客户端的命令请求；二是子进程带有数据库数据副本，避免使用锁来保证数据安全。

为了记录重写期间的新写命令，Redis 设置了 AOF 重写缓冲区。待重写完成，将缓冲区中的命令写入新的 AOF 文件，确保数据不丢失。

AOF概述

AOF备份可靠，数据丢失概率低。AOF 文件是可读的文本，便于通过操作文件恢复误操作。AOF 持久化机制为 Redis 提供了一种较为稳健的数据备份方式，但在实际应用中，需要根据具体的业务需求和性能要求，合理选择持久化策略或结合使用 RDB 等其他持久化方式。

RDB 原理

RDB 持久化的核心原理是周期性地创建 Redis 数据库状态的快照。它以一种高效的二进制格式将内存中的数据进行序列化，并将其保存到指定的 RDB 文件中。这种方式类似于为数据库状态拍摄“照片”，记录特定时刻数据库中所有键值对的信息。在执行 RDB 持久化时，Redis 会遍历内存中的数据结构，将键、值以及相关的元数据进行编码和压缩，以减少文件大小并提高存储和恢复的效率。

RDB 触发机制

RDB 持久化的触发方式主要有以下几种：

1. 自动触发：通过在 Redis 配置文件中精心设置相关规则，Redis 能够实现智能的自动 RDB 生成。例如，可以定义在指定的时间间隔（如 900 秒、300 秒或 60 秒）内，如果数据库发生了一定数量（如 1 次、10 次或 10000 次）的修改操作，Redis 就会自动触发 BGSAVE 命令来创建 RDB 文件。
2. 手动触发：可以通过执行 SAVE 或 BGSAVE 命令来手动触发 RDB 持久化。
   • SAVE 命令：当执行此命令时，Redis 会阻塞当前主线程，全力投入到 RDB 文件的创建工作中。然而，由于这种阻塞特性，可能会导致 Redis 在生成 RDB 文件期间无法响应其他客户端的请求，因此在生产环境中应谨慎使用。

• BGSAVE 命令：这是一种更为优雅和实用的手动触发方式。执行该命令后，Redis 会迅速在后台创建一个子进程来负责 RDB 文件的生成工作。在此期间，Redis 主进程能够继续处理客户端的请求，确保服务的连续性和响应性。

RDB 优点

1. 恢复速度快：RDB 文件是一个经过优化的紧凑二进制文件，完整包含了数据库在特定时刻的状态信息。在进行数据恢复时，Redis 能够快速读取和解析这个文件，迅速将数据库恢复到指定的状态，极大地减少了恢复时间，尤其在处理大规模数据时优势明显。
2. 文件体积小巧：相较于 AOF （Append Only File）持久化方式，RDB 文件通常在大小上更为精简。这是因为 RDB 是对数据库状态的一次性快照，而 AOF 则记录了每一条写操作命令，随着时间的推移，AOF 文件可能会因为大量的命令记录而变得较大。
3. 易于备份和迁移：RDB 文件的简洁性和完整性使其非常适合作为数据备份的选择。无论是进行定期的异地备份，还是在不同环境之间迁移数据，RDB 文件都更高效。

RDB 缺点

1. 数据可能丢失风险：由于 RDB 是按照一定的时间间隔或数据修改次数来生成快照，如果在两次快照之间发生了意外故障，那么自上一次快照以来的新数据修改可能会丢失。这对于那些对数据实时性和完整性要求极高的应用场景可能存在一定的局限性。
2. 资源消耗集中：在生成 RDB 文件的过程中，特别是当数据库中的数据量庞大时，Redis 可能会消耗较多的 CPU、内存和磁盘 I/O 资源。这可能会在短时间内对系统性能产生一定的影响，尤其是在资源紧张的服务器环境中。

RDB 应用场景

1. 大规模数据存储与恢复：当 Redis 数据库中的数据量巨大时，RDB 因其快速的恢复特性，能够在较短时间内将数据库恢复到可用状态，适用于需要频繁进行大规模数据恢复的场景。
2. 数据备份策略：作为定期的完整数据备份选项，RDB 文件可以与其他增量备份方式相结合，构建多层次的数据保护体系。
3. 对恢复时间敏感的业务：对于那些对系统停机时间和数据恢复速度有严格要求的业务，如金融交易、实时在线服务等，RDB 能够迅速恢复数据库状态，减少业务中断的时间。

RDB与AOF关系

Redis 还提供了 AOF 持久化方式，AOF 以日志形式记录了所有的写操作命令，确保数据的完整性。在实际应用中，可以根据具体的业务需求和性能要求灵活选择使用：

• 单独使用 RDB ：适用于对数据丢失有一定容忍度，更注重恢复速度和存储空间效率的场景。
• 单独使用 AOF ：适用于对数据完整性要求极高，愿意牺牲一定性能来保证每一条写操作都被记录的场景。
• 结合使用 RDB 和 AOF ：通过 RDB 提供定期的完整备份，结合 AOF 保证数据的实时完整性，实现性能与数据安全的平衡。