6.1 Redis持久化机制概述
对于Redis而言,持久化机制是指把内存中的数据存储为硬盘文件,这样当Redis重启或服务器故障时能根据持久化后的硬盘文件恢复数据.
6.1.1 基于AOF的持久化机制
在AOF持久化的过程中,会以日志的方式记录每个Redis"写"命令,并在Redis服务器重启时重新执行AOF日志文件中的命令,从而达到"恢复数据"的效果.如下图示:
当AOF持久化功能打开时,每当发生写命令,该命令就会被记录到AOF缓冲区里,AOF缓冲区会根据事先配置的策略定期与硬盘文件进行同步操作,而且当AOF文件大道一定程度后,该文件会被重写,即在不影响持久化结果的前提下进行压缩.此外,当Redis服务器重启时,会加载硬盘上的AOF日志文件,以实现数据恢复的效果.
当Redis因发生故障而重启时,Redis服务器会按照如下步骤,根据AOF日志文件恢复数据:
step1. 创建一个伪客户端(fake client)
之所以叫伪客户端,是因为该客户端在本地,不带有任何网络连接,但该伪客户端执行命令的效果和真实的带网络的客户端没有任何差别
step2. 执行命令
该伪客户端从AOF日志文件里依次读取每条写命令并执行,直到完成所有写命令
6.1.2 基于RDB的持久化机制
基于RDB的持久化方式会把当前内存中所有Redis键值对数据以快照(snapshot)的方式写入硬盘中,如果需要恢复数据,把快照文件读到内存中即可.
RDB快照文件是经压缩的二进制格式的文件.它的存储路径可以在Redis服务器启动前通过配置参数来设置,也可以在Redis运行时通过命令来设置
2种方式可以触发RDB持久化机制:
SAVE和BGSAVE等命令手动触发根据配置文件中设定的方式定期把数据写入快照
基于RDB的持久化方式比较适合数据备份和灾备的场景,但RDB无法实现即时备份.
虽然RDB无法实现实时备份,但相比于AOF,RDB持久化也有其优点:
备份文件体积较小:RDB生成的是数据集的二进制快照,通常比AOF文件要小得多.因为AOF记录了所有的写操作命令,随着时间的推移,AOF文件可能会变得非常大
快速数据恢复:由于RDB是数据的快照,当Redis启动时,它可以直接加载RDB文件进行数据恢复,这通常比重新执行AOF文件中的所有命令要快得多
低I/O开销:RDB的持久化是间隔一段时间进行的(基于配置的时间和数据变化阈值),而不是像AOF那样每次写操作都要进行磁盘I/O.这意味着在高并发写入的场景下,RDB可能会提供更好的性能
简单的备份策略:RDB文件提供了一个非常简单的方式来备份Redis数据.管理员可以简单地将RDB文件复制到另一个位置或系统,以实现数据备份
避免潜在的AOF问题:尽管AOF提供了更精确的数据恢复能力,但它也可能带来一些问题,例如文件过大、AOF重写带来的性能问题等.使用RDB可以避免这些问题
反之,与RDB相比,AOF(Append Only File)持久化方式具有以下优点:
数据持久性更强:AOF持久化记录了所有的写操作命令,因此它可以提供更强的数据持久性.即使在系统故障后,只会丢失最后一次
fsync以来的数据.与RDB相比,AOF通常可以提供更短的数据丢失窗口更为健壮:由于AOF文件是一个命令日志,即使文件中的部分数据因为某些原因变得损坏或不一致,Redis也可以加载文件中的大部分数据.而RDB文件,如果损坏,可能会导致整个文件都无法加载
实时或近实时备份:你可以配置Redis以多种模式写入AOF文件:每次写操作后、每秒或者完全由操作系统决定.这意味着,相对于RDB的定期快照,AOF可以提供更为实时的数据备份
更精确的数据恢复:由于AOF记录了每一个写操作,所以在系统重启后,它可以通过重新执行这些操作来恢复数据,从而实现非常精确的数据恢复
易于人工干预和理解:AOF文件是一个文本文件,记录了所有的Redis写命令.这意味着,在必要时,你可以手动编辑AOF文件(尽管不推荐这么做),或者更容易地理解其内容
Last updated
