手绘10张图,细谈Redis 持久化,详解RDB和AOF及混合机制

发布网友发布时间：2024-10-23 01:59

共1个回答

热心网友时间：1天前

Redis持久化机制的目的是在服务宕机后，能够快速恢复数据，避免从后端数据库恢复带来的性能压力和延迟。通过持久化，Redis可以在发生故障时，使用数据快照或日志记录快速恢复状态。主要有三种持久化方案：RDB（快照）、AOF（日志）和虚拟内存（VM）及DISKSTORE方式，但后两者目前官方不推荐使用。

在Redis的持久化方案中，RDB（Redis DataBase）采用快照方式，将当前进程的数据生成一个快照保存到磁盘上。这个快照仅包含某一时刻的数据状态，并且快照中的值要早于或等于内存中的值。RDB持久化可以通过手动触发（使用save或bgsave命令）或自动触发（在特定情况下）进行。

自动触发RDB持久化的情况包括：配置文件中的RDB参数设置、内存快照周期性执行条件、服务异常情况下禁止写操作、启用LZF压缩算法（rdbcompression）和启用校验码（rdbchecksum）等。

深入理解RDB持久化，关键在于其背后的Copy-on-Write机制，确保快照过程中数据不被修改。在快照操作中，Redis会fork出一个子进程专门执行快照，主进程则继续处理客户端请求，数据变化会在内存中以副本形式存在，直到快照操作完成才同步到原内存区域。快照间隔时间（t值）的设置非常重要，t值越小，数据恢复越接近实时。

AOF（Append Only File）采用写后日志方式，先执行命令再记录到内存，然后将命令写入AOF文件。AOF日志通过append、write和sync三个步骤记录命令执行情况。三种同步策略（Always、Everysec、No）体现了性能与可靠性的权衡。

Redis在配置AOF时，需要设置appendonly、appendfilename、appendfsync、no-appendfsync-on-rewrite等参数来控制AOF文件的开启、命名、同步策略和重写机制。AOF的自动重写策略基于文件大小和上次重写后的大小进行判断，确保在数据量增长时能够及时更新文件。

了解AOF重写过程，可以发现它通过创建新AOF文件替换旧文件，去除冗余命令，从而实现“瘦身”。重写过程涉及两个缓冲区，一个用于记录新命令，一个用于保留旧命令，以确保数据一致性。AOF重写策略包括最小文件大小（auto-aof-rewrite-min-size）和增量百分比（auto-aof-rewrite-percentage）。

在Redis 4.0版本中引入了RDB和AOF的混合使用方式，通过在两次全量快照之间使用AOF记录命令，避免频繁fork对主线程的影响，同时减少了AOF文件的大小，降低了重写开销。这种方法结合了RDB快速恢复和AOF记录命令的优点，实际应用中被广泛采用。

从持久化中恢复数据，只需要重新启动Redis服务即可。当服务器同时存在RDB和AOF文件时，通常优先加载AOF文件，因为它能够提供更完整、丢失数据量更小的数据恢复。