海南新闻网

JAVA面试题:Redis的持久化机制

Qianfeng JAVA Development Institute我想分享3天前

面试问题

有什么方法可以坚持Redis?不同持久性机制有哪些优缺点?底层持久性机制是如何实现的?

测试现场分析

如果Redis只是将数据缓存在内存中,如果它已关闭,然后重新启动,内存中的数据将会丢失!

您必须使用Redis的持久性机制以异步和异步方式将数据写入磁盘以将数据写入磁盘。

如果Redis关闭,重新启动它并在磁盘保持之前自动从磁盘加载一些数据,可能会丢失一些数据,但至少不会丢失所有数据

它针对的是Redis的生产环境可能遇到的一些问题。如果Redis挂起然后重新启动,则内存中的数据不会丢失。数据重启后能否恢复?

1 Redis持久性的重要性

许多学生已经阅读了一些redis材料和书籍,当然他们可能已经看过一些redis视频课程

事实上,所有的信息都会解释redis的持久性,但是有一个问题,到目前为止我还没有看到任何人非常仔细地解释它,redis的持久性意义

Redis持久性,RDB,AOF,差异,它们各自的特征是什么,以及适合哪种场景

什么是Redis的企业级持久性解决方案,以及与之结合使用哪些企业级方案?

redis持久性的含义在于故障恢复

例如,如果将redis部署为缓存缓存,则可以保存一些重要数据。

如果没有持久性,redis将在遇到灾难性故障时丢失所有数据

如果您通过持久性将数据保留在磁盘上,然后定期同步并备份到某些云存储服务,则可以保证数据不会丢失,或者您可以恢复部分数据。

image.php?url=0MZWr7gqgj

我们已经知道,对于企业级redis架构,持久性不会降低。

企业级redis集群架构:海量数据,高并发性,高可用性

持久性主要用于灾难恢复,数据恢复,也可以归类为高可用性链接。

例如,如果您的Redis已关闭,您所要做的就是让Redis可用并尽快上市!

重启Redis并让它尽快提供服务,但如前一段所述,如果你不进行数据备份处理,即使Redis启动,数据也会消失!什么是可用的?

很可能是大量的请求过来了,缓存无法命中,Redis中找不到数据,这次造成缓存雪崩,它会去MySQL数据库查找,突然MySQL进行高并发,停机时间!

MySQL崩溃,你无法找到恢复到Redis的数据。 Redis数据来自哪里?它来自MySQL!

具体的完整缓存雪崩场景,以及企业级解决方案,稍后再讨论

如果您在Redis持久性,备份和恢复解决方案方面做得很好,那么即使您的Redis出现故障,您也可以通过备份数据快速恢复数据,并在恢复后立即提供服务

2 Redis持久性机制

RDB和AOF简介

image.php?url=0MZWr763ES

RDB持久性机制

在Redis中对数据执行定期持久性

AOF机制

将命令写为日志,以仅附加模式写入日志文件,并在Redis重新启动时通过回放日志中的write命令重新配置整个数据。如果我们希望Redis仅用作纯内存缓存,我们还可以禁用所有持久性机制,如RDB和AOF

通过RDB或AOF,您可以将数据保存在Redis内存中,然后您可以将这些数据备份到您需要的其他位置。

如果Redis关闭,则服务器上的内存和磁盘上的数据将丢失。您可以从云服务复制以前的数据,将其放在指定的目录中,然后重新启动Redis。 Redis将自动跟踪持久数据文件中的数据。数据,以恢复内存中的数据,继续提供外部服务

如果同时使用RDB和AOF持久性机制,那么当Redis重新启动时,AOF将用于重建数据,因为AOF中的数据更完整!

2.1深入研究RDB

2.1.1 RDB的优点

RDB将生成多个数据文件,每个文件在某个时刻代表Redis中的数据。这种多数据文件方法非常适合冷备用,并且可以将此完整数据文件发送到远程安全性。存储,例如亚马逊的S3云服务,可用于阿里云在中国的ODPS分布式存储,并定期使用预定的备份策略备份Redis中的数据

RDB对Redis的外部读写服务影响很小,这可以使rRedis保持高性能,因为Redis主进程只分配子进程,让子进程执行RDB

与AOF持久性机制相比,基于RDB数据文件直接重启和恢复Redis进程更快。

2.1.2 RDB的缺点

如果你想在Redis失败时丢失尽可能少的数据,那么RDB没有AOF。

通常,RDB数据快照文件每5分钟或更长时间生成一次。如果Redis在此过程中崩溃,那么尚未保留的数据将会丢失。

每次RDB在fork子进程中执行RDB快照数据文件时,如果数据文件特别大,可能会导致客户端提供的服务暂停几毫秒甚至几秒钟。

RDB丢失了数据

2.2深入AOF

image.php?url=0MZWr76e72

AOF重写原则分析

image.php?url=0MZWr7TWpF

2.2.1 AOF的优点

更好地避免数据丢失

通常,AOF将每1秒通过子进程执行一次fsync操作,并丢失最多1秒的数据

仅附加模式写入

因此,磁盘寻址没有开销,写入性能高,而且文件不易损坏,即使文件尾部损坏,也很容易修复

即使日志文件太大,也会发生后台重写操作,这不会影响客户端的读写操作

因为重写日志将压缩指令并创建需要还原的最小日志。创建新日志时,仍会像往常一样编写旧日志文件。当新的合并日志文件准备就绪时,交换旧的和新的日志文件!

命令以非常易读的方式记录

此功能非常适用于灾难性意外删除的紧急恢复。

删除flushall命令,然后放回AOF文件,所有数据都可以通过恢复机制自动恢复。

2.2.2 AOF的缺点

对于相同的数据,AOF日志通常大于RDB快照

打开AOF后,编写QPS会低于RDB,因为AOF通常配置为fsync每个s的日志文件,当然每个s fsync,性能仍然很高

在过去,AOF有一个错误,由AOF记录。恢复数据后,相同的数据未恢复。

像AOF这样更复杂的基于命令的日志/合并/回放方法每次都比基于RDB的完整数据快照持久性更容易受到攻击

但是,AOF是为了避免重写过程造成的错误。因此,每次重写都不是基于旧的指令日志,它是基于当时内存中的数据,因此鲁棒性会更好。

3选择RDB AOF

不要只使用RDB,因为这会导致您丢失大量数据

也不要只使用AOF,因为有两个问题

2.1你通过AOF做冷待机,没有RDB做冷待机,恢复速度更快

2.2 RDB每次简单粗鲁时都会生成数据快照,更加强大,可以避免AOF的错误,这是一种复杂的备份和恢复机制。

综合使用AOF和RDB

3.1使用AOF确保数据不会丢失,作为数据恢复的首选

3.2使用RDB进行不同级别的冷备用,当AOF文件丢失或损坏不可用时,还可以使用RDB快速实现数据恢复

收集报告投诉