Redis两大持久化方式

news2025/1/17 0:00:32

Redis具有两种主要的持久化方式：RDB（Redis Database Backup）和AOF（Append-Only File）。
在这里插入图片描述

RDB（Redis Database Backup）
RDB是Redis进行快照持久化的一种方式。它周期性地将内存中的数据集快照持久化到硬盘上的RDB文件中。RDB文件保存了某个时间点上的Redis数据集的快照。

在这里插入图片描述

RDB 的执行原理如下：

触发机制
RDB 快照生成可以通过手动执行 SAVE 或者 BGSAVE 命令，或者在配置文件中设置自动触发快照生成的条件。BGSAVE 是后台异步执行，不会阻塞主线程。
内存快照
当执行 BGSAVE 命令时，Redis 会派生出一个子进程，子进程负责将 Redis 内存中的数据集写入临时文件。此过程中，父进程（主 Redis 进程）可以继续处理客户端请求，因为子进程负责数据的持久化，不影响主进程的运行。
写入临时文件
子进程将内存数据写入一个临时文件中。这个过程中，Redis 使用了 copy-on-write（写时复制）机制，保证了在持久化的同时不影响 Redis 主进程对数据的操作。
替换旧 RDB 文件
当快照写入完毕后，Redis 会用新的 RDB 文件替换旧的 RDB 文件，通常会使用临时文件先写入，写入成功后再原子性地替换。
数据恢复
当需要恢复数据时，Redis 可以直接通过加载 RDB 文件来还原内存中的数据状态，将 RDB 文件重新加载到内存中进行数据恢复。
数据持久化时间间隔
在配置文件中可以设置数据持久化的时间间隔，以决定执行快照的频率。较长的时间间隔可能会导致较多数据丢失，较短的时间间隔会增加持久化的开销，因此需要权衡设置。

AOF（Append-Only File）
AOF记录了所有写命令，以追加（append）方式保存到文件中，使得可以重新执行这些命令来恢复原始数据集。

在这里插入图片描述

写入模式：AOF 文件记录了所有发生的写命令（例如 SET、INCR、DEL 等），以文本形式记录，每个命令以一行的方式追加到文件的末尾。
AOF Rewrite：为了避免 AOF 文件过大，Redis 会周期性地对 AOF 文件进行重写（AOF Rewrite）。重写的过程中会创建一个新的 AOF 文件，这个新文件仅包含了重写时刻之后的有效写命令，且采用紧凑的格式。重写后，旧的 AOF 文件被删除，新的 AOF 文件替换原来的文件，以减小 AOF 文件的大小。
启动时恢复数据：Redis 在启动时会先加载 AOF 文件来恢复数据，通过逐条重新执行文件中记录的命令，将数据还原到内存中。
AOF 文件的同步：Redis提供了多种AOF同步策略，如always（每条命令都同步到磁盘），everysec（每秒同步一次），no（由操作系统决定同步时间点）。这些同步策略可以影响数据的持久性与性能之间的平衡。

选择使用 RDB 还是 AOF（或两者结合）应根据业务需求和系统特点做出考量。以下是一些指导方针，以便更好地选择适合的持久化方式：

RDB 的适用场景：
对数据恢复速度要求高：RDB 文件是一种快速恢复数据的方法，适合对快速恢复有需求的场景。
定期备份：适用于进行定期全量备份和快速恢复数据的场景。
较少关注数据完整性：对于某些业务场景，如临时数据或能够容忍某些数据丢失的情况，可以考虑使用RDB方式。
AOF 的适用场景：
数据完整性要求高：AOF 记录了每次写操作，提供了更好的数据完整性保障，适合对数据完整性要求高的场景。
实时增量备份：适用于对数据实时进行增量备份，对业务数据的每一次写操作都进行持久化。
能接受稍慢一些的恢复速度：相对于 RDB，AOF 文件恢复速度可能稍慢一些，但提供了更好的数据完整性保障。
RDB 与 AOF 结合的适用场景：
结合使用 RDB 和 AOF 可以兼顾快速的恢复速度和数据完整性，适合对数据完整性和恢复速度都有要求的业务场景。这种结合方式可以充分发挥两者各自的优势，提高持久化的可靠性。
总体指导方针：
数据重要性：如果数据完整性至关重要，则倾向于选择 AOF。
恢复速度需求：如果对恢复速度要求很高，则倾向于选择 RDB。
数据量和性能：AOF 文件可能较大，会影响性能，需根据数据量和系统特点来决定使用哪种方式或其组合。