Java开发

您所在的位置:网站首页 redis持久化的两种方式,描述错误的是 Java开发

Java开发

2024-07-11 16:24| 来源: 网络整理| 查看: 265

Java开发-面试题-0009-Redis持久化方式RDB和AOF

更多内容欢迎关注我(持续更新中,欢迎Star✨)

Github:CodeZeng1998/Java-Developer-Work-Note

技术公众号:CodeZeng1998(纯纯技术文)

生活公众号:好锅(Life is more than code)

CSDN: CodeZeng1998

其他平台:CodeZeng1998、好锅

Redis 持久化方式

Redis 支持两种主要的持久化方式:**RDB(Redis Database Backup file)**和 AOF(Append Only File)。这两种方式可以单独使用,也可以结合使用,以确保数据的安全性和恢复能力。

RDB(Redis Database Backup file)

内容:

把内存中的所有数据都记录到磁盘中,当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。RDB 是一种快照存储机制,Redis 会在指定的时间间隔内将数据集写入磁盘,生成一个 RDB 文件。这个 RDB 文件是一个二进制压缩文件,包含了数据集的完整快照。

配置:

# 由Redis主进程来执行RDB,会阻塞所有命令 save # 开启子进程执行RDB,避免主进程受到影响 bgsave

配置文件中可以设置 选项,指定在多少秒内如果发生多少次写操作就进行一次 RDB 持久化。例如:

# 900 秒(15 分钟)内至少有 1 次写操作 save 900 1 # 300 秒(5 分钟)内至少有 10 次写操作 save 300 10 # 60 秒内至少有 10000 次写操作 save 60 10000

优缺点:

优点:适合大规模数据恢复,恢复速度快,RDB 文件较小。缺点:可能会丢失最近一次快照后到崩溃前的所有数据。

原理:

Redis 通过 fork 命令创建一个子进程,子进程将数据写入临时文件。当子进程完成写操作后,临时文件会替换旧的 RDB 文件。因为是子进程执行写操作,主进程不会受到影响,可以继续处理客户端请求。

bgsave开始时会fork主进程得到子进程,子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术:

当主进程执行读操作时,访问共享内存;当主进程执行写操作时,则会拷贝一份数据,执行写操作。

页表:记录虚拟地址与物理地址的映射关系。

Redis中的RDB是用于将内存中的数据快照保存到磁盘上的一种持久化方式。其执行原理如下:

fork:在执行RDB快照时,Redis主进程会通过fork系统调用创建一个子进程。子进程会与主进程共享内存数据。Copy-on-Write:由于采用了Copy-on-Write(写时复制)技术,子进程在创建时并不会立即拷贝主进程的整个内存数据,而是共享主进程的内存。当主进程执行读操作时,仍然可以访问共享的内存;当主进程执行写操作时,会首先拷贝一份数据,然后在拷贝的数据上执行写操作,从而避免直接修改共享内存。写入RDB文件:子进程在完成fork后,会将内存中的数据读取出来,并写入到一个新的RDB文件中。这一过程中,主进程可以继续处理客户端的请求,不会被阻塞。替换旧文件:当子进程成功地将数据写入新的RDB文件后,会将该文件替换掉旧的RDB文件,以保证数据的一致性。

Copy-on-Write详细步骤

页面表操作: 当Redis主进程fork创建子进程时,操作系统会创建子进程的页表,这些页表条目指向主进程的内存页。这些内存页最初被标记为只读,以便主进程和子进程都可以读取这些页面而无需实际复制。 主进程的读写操作: 读操作:当主进程执行读操作时,它直接读取共享内存页面,不会引发任何额外的开销。写操作:当主进程需要写入数据时,操作系统会检测到写操作并触发页面复制(写时复制)。具体步骤如下: 操作系统会创建一个新的物理内存页,并将需要写入的数据复制到新页面。更新主进程的页表,将相应的页表条目指向新的物理内存页。子进程继续指向原始的内存页,不会受到主进程写操作的影响。 子进程的数据处理: 子进程在fork完成后开始读取内存数据并将其写入RDB文件。如果主进程在子进程进行数据快照期间进行了写操作,子进程不会看到这些修改,因为这些修改是在新的物理内存页上进行的,而子进程仍然指向原始的内存页。

通过上述步骤,Redis在实现RDB持久化时可以确保数据一致性,同时尽量减少对主进程的影响,从而保持高性能。

RDB执行详细步骤

触发RDB保存:

可以通过手动执行SAVE或BGSAVE命令来触发RDB保存。Redis配置文件中也可以设置定时保存规则,如save 900 1表示每900秒至少有1次修改时触发RDB保存。

fork子进程:

Redis主进程接收到BGSAVE命令后,会调用fork系统调用创建一个子进程。此时,子进程和主进程共享相同的内存数据。

写时复制:

在fork之后,主进程继续处理客户端请求,并且这些请求可能会修改内存数据。由于采用了写时复制技术,当主进程需要修改数据时,会拷贝一份数据进行修改,而子进程继续访问原始的共享内存数据。

子进程写RDB文件:

子进程在fork完成后,会开始将内存数据写入新的RDB文件。这个过程不会阻塞主进程的正常操作。子进程会遍历Redis中的所有数据,并将其序列化写入RDB文件。

完成并替换RDB文件:

子进程完成数据写入后,会将新的RDB文件替换掉旧的RDB文件。

主进程在收到子进程完成信号后,会清理子进程资源,并继续正常工作。

AOF(Append Only File)

内容:

AOF 是一种日志文件存储机制,Redis 会将每次写操作记录到日志文件中。AOF 文件是一个追加日志文件,记录了所有修改数据库的操作命令。

原理:

每次写操作后,Redis 会将命令追加到 AOF 文件末尾。

Redis 提供了 appendfsync选项,决定何时将 AOF 缓存区的数据写入磁盘,有三种模式:

always:每次写操作后都同步到磁盘,最安全,但性能最低。everysec:每秒同步一次,性能和安全的折中,最多丢失1秒的数据。no:不主动同步,由操作系统决定何时写入,性能最高但最不安全,可能丢失大量数据。

配置:

AOF默认是关闭的,需要修改redis.conf配置文件来开启AOF:

# 是否开启 AOF 功能,默认是 no appendonly yes # AOF 文件的名称 appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配:

# 表示每执行一次写命令,立即记录到AOF文件 appendfsync always # 写命令执行完先放入AOF缓冲区,然后表示每隔1秒将缓冲区数据写到AOF文件,是默认方案 appendfsync everysec # 写命令执行完先放入AOF缓冲区,由操作系统决定何时将缓冲区内容写回磁盘 appendfsync no

优缺点:

优点:数据丢失较少,因为每次写操作都会记录。缺点:AOF 文件通常比 RDB 文件大,恢复速度较慢。 RDB 和 AOF 的对比 RDBAOF持久化方式定时对整个内存做快照记录每一次执行的命令数据完整性不完整,两次备份之间会丢失(可能丢失最近一次快照后的数据)丢失数据较少,取决于刷盘策略(appendfsync)文件大小会有压缩,文件体积较小记录命令,文件体积较大宕机恢复速度较快较慢数据恢复优先级低,因为数据完整性不如AOF高,因为数据完整性更高系统资源占用高,大量CPU和内存消耗低,主要是磁盘IO资源,但AOF重写时会占用大量的CPU和内存资源使用场景可以容忍数分钟的数据丢失,追求更快的启动速度对数据安全性要求较高常见 AOF 中的 bgrewriteaof

AOF因为是记录命令,AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作,但只有最后一次写操作才有意义。通过执行 bgrewriteaof 命令,可以让AOF文件执行重写功能,用最少的命令达到相同效果。

BGREWRITEAOF 命令执行时,Redis会进行以下步骤:

启动子进程:

Redis主进程通过fork系统调用创建一个子进程,用于执行AOF重写操作。

AOF重写:

子进程开始遍历当前的内存中的数据,将其中的写命令以优化的格式写入到一个临时文件中。优化的格式通常指合并多个连续的写命令,去除无效的命令等,以减少AOF文件的体积。

替换旧AOF文件:

当子进程完成AOF重写并生成了新的AOF文件后,它会将新文件重命名为旧文件的名称,从而替换掉旧的AOF文件。这个操作是原子的,确保在任何时候Redis都可以保持数据的一致性。

清理临时文件:

子进程完成AOF文件替换后,会清理临时生成的AOF文件。

优点

减少AOF文件大小:通过去除冗余命令和优化写入格式,可以显著减少AOF文件的大小,从而节省磁盘空间。提高读取性能:AOF重写可以在不影响主进程的情况下进行,因此对Redis服务器的性能影响较小。提高AOF文件的可读性:优化后的AOF文件更易于人类阅读,也更容易进行后续处理和分析。

注意事项

耗时操作:AOF重写可能会消耗一定的CPU和磁盘IO资源,尤其是在处理大量数据或频繁写入的情况下。配置策略:可以通过配置文件中的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size选项来设置触发AOF重写的条件。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置:

# AOF文件比上次文件 增长超过多少百分比则触发重写 auto-aof-rewrite-percentage 100 # AOF文件体积最小多大以上才触发重写 auto-aof-rewrite-min-size 64mb

通过使用 BGREWRITEAOF 命令,Redis可以有效地管理和优化AOF文件,确保数据持久化的可靠性和效率。

以上就是本文相关的所有内容了,如果发现有误欢迎评论指正,更多内容欢迎各位关注。在这里插入图片描述

上图是由 Microsoft Designe 生成的

关键词:Pok é mon’s Velociraptor and Tyrannosaurus Rex

更多内容欢迎关注我(持续更新中,欢迎Star✨)

Github:CodeZeng1998/Java-Developer-Work-Note

技术公众号:CodeZeng1998(纯纯技术文)

生活公众号:好锅(Life is more than code)

CSDN: CodeZeng1998

其他平台:CodeZeng1998、好锅



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3