Redis持久化----RDB和AOF 的区别
一、Redis的持久化机制概述
RDB持久化机制:
- RDB持久化机制是一种将Redis在内存中的数据保存到磁盘上的方式,保存的数据是某个时间点的快照。
- 在RDB持久化机制中,Redis会周期性地将内存中的数据快照写入磁盘,保存为一个RDB文件。
- 通过快照的方式将数据保存在磁盘上,可以减小数据集的大小,并且在恢复大数据集时速度较快。
- 优点:简单、高效,适合大规模数据的备份和恢复。
- 缺点:可能会丢失最后一次快照之后的数据,不适合对数据丢失要求严格的场景。
AOF持久化机制:
- AOF持久化机制将Redis服务器执行的所有写操作记录到一个日志文件中,采用追加的方式写入。这确保了数据不会丢失。
- AOF文件保存的是Redis服务器执行的原始命令,因此具有很好的可读性。
- AOF文件通常会比RDB文件大,但可以提供更好的数据持久性,数据丢失的概率更低。
- 优点:提供更好的数据持久性,可以最大程度上避免数据丢失。
- 缺点:相对于RDB,AOF文件较大,恢复速度相对较慢。同时,AOF文件的写入频率较高,对性能产生一定影响。
运行时查看持久化信息:
查看 RDB 持久化状态:使用 INFO persistence 命令,返回结果中的 rdb_last_save_time 字段显示了最后一次执行 RDB 持久化的时间。可以通过定期执行 LASTSAVE 命令来获取最后一次成功执行 RDB(快照)持久化的时间。
查看 AOF 持久化状态:使用 INFO persistence 命令,返回结果中的 aof_enabled 字段显示了 AOF 持久化是否开启。
运行命令:
CONFIG GET save
CONFIG GET appendonly
二、RDB持久化机制
RDB持久化机制就像是在玩电脑游戏时,你不想从头重新开始,就想着在特定关卡或者达到一定分数时,把当前游戏存档下来,下次再玩的时候,直接加载存档就可以继续玩了。
首先,得告诉Redis要定期存档数据,就像给游戏设置一个自动存档的功能一样。向Redis发送指令告诉它每隔多久就要存档一次,或者当修改的key超过一定的数量时要存档。这就是触发条件,就好比是设定游戏存档的条件。
一旦触发了存档条件,Redis就要开始行动了。它会整理内存中的所有数据,就好比是整理要存档的游戏状态,然后把这些数据写入一个临时文件里,相当于是把游戏状态存到了一个暂时的存档文件里。
接下来,Redis会将这个临时文件保存到硬盘上,并将其重命名为RDB文件。这就相当于是把暂时存档文件变成了一份正式的游戏存档文件。这是一个非常重要的步骤,因为它确保了无论何时,RDB文件都是完整的。
这个RDB文件就相当于游戏的存档文件,里面包含了所有数据的状态。当Redis服务器启动时,它会读取这个RDB文件,然后把这些数据重新加载到内存中,就好比是通过加载游戏存档文件,从而恢复到之前的状态。这样,Redis就会从之前存档的位置继续运行,就好像是游戏恢复到了存档的地方一样。
触发 RDB 文件的生成有以下两种方式:
手动触发:通过执行 SAVE 或 BGSAVE 命令。
自动触发:基于 Redis 配置文件中的 save 指令设置的条件。(默认是通过 BGSAVE 命令来触发的)
redis 配置文件 save 指令设置:
save 3600 1 # 3600秒内如果超过1个key被修改则生成 RDB
save 300 100 # 300秒内如果超过100个key被修改则生成 RDB
save 60 10000 # 60秒内如果超过10000个key被修改则生成 RDB
优点
- RDB持久化机制通过生成内存快照的方式保存数据到磁盘,这样在数据恢复时只需加载一个文件,能够快速地恢复整个数据集。
- 由于RDB文件是一个快照,它只包含了某个时间点的数据,因此RDB文件相对较小(因为经过了压缩)。这对于备份、恢复大型数据集是非常有利的。
- RDB文件是一个完整的快照,因此在需要恢复数据时,可以确保数据的完整性。
- RDB文件是一个二进制文件,因此可以很方便地进行备份和迁移,也更容易实现数据的异地备份。
缺点
- DB持久化机制是周期性地进行数据快照,因此在数据快照之间的时间段内,如果发生宕机或故障,可能会丢失最后一次快照之后的数据。
三、AOF持久化机制
对于AOF持久化机制时,可以这么想:想象在写日记,每当发生一件重要的事情都会拿出日记本,追加写上这件事的内容。这样做的好处是不会漏掉任何一件重要的事情,而且日记本记录的内容也非常详细。
原理和工作流程:
1)在AOF持久化机制中,Redis会记录所有写操作,这包括对数据进行插入、更新、删除等所有的写入操作。每当这些写操作发生时,Redis会将相应的命令追加到AOF文件的末尾。
2)随着时间的推移,AOF文件会持续地通过追加写入命令来不断增长,就像是不断地在日记本中写入新的内容。
3)当Redis服务器重新启动时,它会通过重新执行AOF文件中存储的命令来恢复数据,简单来说是重新读一遍日记本中的所有事件,从而还原出数据状态。
优点
- AOF文件中记录了Redis执行的所有写操作,可以提供更可靠的数据持久性,避免数据丢失。
- AOF文件保存的是Redis服务器执行的原始命令,在恢复数据时通过重新执行AOF文件中的命令来还原数据,保证数据的一致性。
- OF文件保存的是Redis服务器执行的原始命令,具有很好的可读性,方便进行数据分析和故障排查。
- 容灾性强。AOF文件的追加写入方式使得即使在发生意外宕机的情况下,数据也不容易丢失,整个AOF文件不易损坏。
缺点
-
由于AOF文件记录了Redis执行的所有写操作,因此在持续运行的过程中,AOF文件会不断增长,导致文件体积较大。
-
由于AOF文件的体积较大,在发生宕机后,需要重新加载整个AOF文件并重放所有命令,会导致较慢的恢复速度。
四、RDB和AOF的混合持久化
Redis 4.0版本引入了RDB和AOF的混合持久化模式(redis默认是开启的rdb的持久化方式),旨在结合两种方法的优点,为用户提供更灵活、更可靠的数据持久化选择。
混合模式开启: aof-use-rdb-preamble 修改为 yes【同时启用 RDB 和 AOF 两种持久化】
开启AOF持久化: appendonly yes
关闭RDB快照功能:save ""
1)工作原理
在 AOF 重写之前,RDB 和 AOF 都是按照它们各自的持久化策略工作的。当 AOF 重写被触发时,混合持久化才开始发挥作用:将当前的数据集会首先以RDB 格式写入新 AOF 文件的顶部,然后再追加新的命令到文件的末尾。
步骤说明:
混合持久化的实现主要是靠主进程和子进程共同来完成的。
子进程:
子进程进行 AOF 重写:
- 首先创建新的 AOF 文件 appendonly.rdb
- 将 Redis 当前的数据生成 RDB 快照写入 appendonly.rdb 文件的开始部分
主进程:
- 主进程先将新的写操作命令写入 AOF 重写缓冲区
- 主进程将 AOF 重写缓冲区的内容追加到 appendonly.rdb文件的 RDB 数据的末尾
- 使用 appendonly.rdb 文件替换旧的 AOF 文件
2)优点
- 快速恢复: 重启时,Redis可以快速加载RDB部分,然后再执行AOF部分,大大减少了数据恢复的时间。
- 数据完整性: AOF部分记录了自上次RDB快照之后的所有写操作,确保了数据的完整性。
- 文件大小优化: 相比纯AOF模式,混合模式的文件通常更小,因为RDB部分是经过压缩的二进制数据。
- 灵活性: 用户可以根据需求调整RDB快照的频率和AOF重写的触发条件。
3)缺点:
- 稍微复杂:因为它结合了两种技术,所以处理起来比单一的 RDB 或 AOF 要复杂一点。
- 可能占更多空间:在某些情况下,保存数据的文件可能会比只使用 RDB 或AOF 的文件要大一些。
- 写入速度:可能会稍慢一些,特别是当数据需要经常被保存到硬盘时(比如当 appendfsync 配置为always时)
4)假如 Redis 的 RDB 和 AOF 持久化都启用,redis 在载入数据的时候,是载入 AOF 文件?还是 RDB 文件?
Redis 会优先载入 AOF 文件来恢复数据,而不是 RDB 文件。这是因为 AOF 文件通常包含了更完整的操作记录,从而能够恢复更完整的数据状态。而 RDB 文件是定时生成的数据快照,所以它可能没有记录到最后一次快照之后发生的所有更改。因此,使用 AOF 文件恢复数据可以提供更高的数据完整性。
5)注意事项
1. 版本兼容性: 混合持久化只在Redis 4.0及以上版本可用。
2. 文件格式变化: 启用混合持久化后,AOF文件的格式会发生变化,可能影响一些依赖于旧格式的工具或脚本。
3. 内存占用: 在进行AOF重写时,可能会短暂增加内存占用。
4. 性能影响: 虽然影响较小,但混合模式可能会对Redis的性能产生轻微影响。
五、如何选择?
RDB持久化机制适合恢复速度要求高、数据频繁变化、备份频繁的场景,而AOF持久化机制适合对数据持久性、一致性要求高、容灾恢复能力要求高的场景。
在性能方面,RDB持久化机制通常在恢复大数据集时性能较好,因为只需要加载一个文件即可恢复整个数据集,而AOF在数据恢复方面由于文件体积较大而导致较慢的恢复速度。另外,RDB文件通常较小,因此在备份和存储大规模数据时性能较好。
在可靠性方面,AOF持久化机制通常能够提供更好的数据持久性,由于AOF文件保存了Redis的原始命令,能够减少数据丢失的概率,而RDB持久化机制在宕机时可能会丢失最后一次快照之后的数据。
在选择Redis持久化策略时,需要考虑以下因素:
- 数据安全性要求: 如果对数据丢失极度敏感,可以选择AOF或混合模式。
- 性能需求: 如果追求最高性能,可以选择RDB或完全关闭持久化。
- 恢复速度: 如果需要快速恢复大量数据,RDB或混合模式更合适。
- 磁盘空间: AOF文件通常比RDB文件大,如果磁盘空间有限,可以考虑RDB或混合模式。
- 应用场景: 对于缓存场景,可以选择RDB或关闭持久化;对于数据存储场景,AOF或混合模式更合适。
对于重要的生产环境,可以使用混合持久化,同时配置适当的RDB快照频率和AOF重写策略。
对于次要的缓存服务,可以仅使用RDB,并降低快照频率。
对于对数据一致性要求极高的场景,可以使用AOF并设置`appendfsync always`。
六、总结
- RDB持久化机制适合于对数据恢复速度要求高、数据变动频率较低、需要对大规模数据进行备份和存储的场景。由于RDB文件体积相对较小,能够较快地恢复整个数据集,适合备份和存储大规模数据。
- AOF持久化机制适合于对数据持久性和可靠性要求高、需要进行数据分析、灾难恢复和故障排查的场景。AOF文件记录了Redis的所有写操作,具有更好的可读性和可靠的数据恢复能力,能够提供更好的数据保护。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
· DeepSeek 开源周回顾「GitHub 热点速览」
2022-04-27 Git -git入门介绍、常用技巧(合并分支)
2022-04-27 数据结构 - 游戏开发中的帧同步与状态同步
2022-04-27 Golang - 如何读取YAML、JSON、INI等配置文件