当前位置:   article > 正文

【高频面试题】 消息中间件_消息中间件面试题

消息中间件面试题

1、RabbitMQ

1.1 RabbitMQ-如何保证消息不丢失

  1. 开启生产者确认机制,确保生产者的消息能到达队列
  2. 开启持久化功能,确保消息未消费前在队列中不会丢失
  3. 开启消费者确认机制为auto,由spring确认消息处理成功后完成ack
  4. 开启消费者失败重试机制,多次重试失败后将消息投递到异常交换机,交由人工处理

首先需要知道消息会在什么地方会丢失

消息从生产者发送到消费者消费的整个流程都可能丢失消息

在这里插入图片描述
生产者确认机制(生产者阶段)

RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。消息发送到MQ以后,会返回一个结果给发送者,表示消息是否处理成功
在这里插入图片描述
消息失败之后如何处理呢?

  1. 回调方法即时重发
  2. 记录日志
  3. 保存到数据库然后定时重发,成功发送后即刻删除表中的数据

消息持久化(mq阶段)

MQ默认是内存存储消息,开启持久化功能可以确保缓存在MQ中的消息不丢失。
在配置 MQ的时候,对交换机、队列可以设置持久化
在这里插入图片描述

消费者确认

RabbitMQ支持消费者确认机制,即:消费者处理消息后可以向MQ发送ack回执MQ收到ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式:

  1. manual:手动ack,需要在业务代码结束后,调用api发送ack。
  2. auto:自动ack,由spring监测listener代码是否出现异常,没有异常则返回ack;抛出异常则返回nack
  3. none:关闭ack,MQ假定消费者获取消息后会成功处理,因此消息投递后立即被删除

我们可以利用Spring的retry机制,在消费者出现异常时利用本地重试,设置重试次数,当次数达到了以后,如果消息依然失败,将消息投递到异常交换机,交由人工处理
在这里插入图片描述


1.2 RabbitMQ消息的重复消费问题如何解决的

首先要知道为什么会重复消费?

如果在消费者消费完消息之后要给mq发送ack确认消息的时候,突然因为网络抖动,或者消费者宕机了,使得消息没有被确认消费,就不会再mq中剔除,造成别的消费者也能拿到消息然后消费

在这里插入图片描述
解决办法有两种:

  1. 每条消息设置一个唯一的标识id(效率高)
    在这里插入图片描述
    每次消费者消费的时候,都要检查数据库里面是否已经有了这个数据(根据唯一标识id),有代表消费过了,就不让消费

  2. 幂等方案:【 redis分布式锁、数据库锁(悲观锁、乐观锁) 】(枷锁效率不高)


1.3 RabbitMQ中死信交换机 ? (RabbitMQ延迟队列有了解过嘛)

延迟队列:进入队列的消息会被延迟消费的队列
场景:超时订单、限时优惠、定时发布
在这里插入图片描述

延迟队列就是由死信交换机+TTL(生存时间)组成的

死信交换机
当一个队列中的消息满足下列情况之一时,可以成为死信(dead letter):

  1. 消费者使用basic.reject或 basic.nack声明消费失败,并且消息的requeue参数设置为false
  2. 消息是一个过期消息,超时无人消费
  3. 要投递的队列消息堆积满了,最早的消息可能成为死信

如果该队列配置了dead-letter-exchange属性,指定了一个交换机,那么队列中的死信就会投递到这个交换机中,而这个交换机称为死信交换机(Dead Letter Exchange,简称DLX)。
在这里插入图片描述
TTL
TTL,也就是Time-To-Live。如果一个队列中的消息TTL结束仍未消费,则会变为死信,ttl超时分为两种情况:

  1. 消息所在的队列设置了存活时间
  2. 消息本身设置了存活时间

在这里插入图片描述

延迟队列插件
在这里插入图片描述

DelayExchange的本质还是官方的三种交换机,只是添加了延迟功能。因此使用时只需要声明一个交换机,交换机的类型可以是任意类型,然后设定delayed属性为true即可。

在这里插入图片描述


1.4 RabbitMQ如果有100万消息堆积在MQ , 如何解决(消息堆积怎么解决)

解决消息堆积有三种种思路:

  1. 增加更多消费者,提高消费速度
  2. 消费者内开启线程池加快消息处理速度
  3. 扩大队列容积,提高堆积上限,采用惰性队列

在声明队列的时候可以设置属性x-queue-mode为lazy,即为惰性队列 基于磁盘存储,消息上限高
性能比较稳定,但基于磁盘存储,受限于磁盘IO,时效性会降低

为什么会出现消息堆积,无非就是消费速度赶上不消费速度

就会导致队列中的消息堆积,直到队列存储消息达到上限。之后发送的消息就会成为死信,可能会被丢弃

在这里插入图片描述

惰性队列
惰性队列的特征如下:

  • 接收到消息后直接存入磁盘而非内存
  • 消费者要消费消息时才会从磁盘中读取并加载到内存
  • 支持数百万条的消息存储

在这里插入图片描述


1.5 RabbitMQ的高可用机制有了解过嘛

高可用无非就是做集群,一个节点宕机了,别的节点还能使用,使得数据不被丢失

普通集群(不推荐)

  • 会在集群的各个节点间共享部分数据,包括:交换机、队列元信息。不包含队列中的消息。
  • 当访问集群某节点时,如果队列不在该节点,会从数据所在节点传递到当前节点并返回
  • 队列所在节点宕机,队列中的消息就会丢失

在这里插入图片描述
镜像集群(也会造成数据丢失)
镜像集群:本质是主从模式,具备下面的特征:

  • 交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份。
  • 创建队列的节点被称为该队列的主节点,备份到的其它节点叫做该队列的镜像节点。
  • 一个队列的主节点可能是另一个队列的镜像节点
  • 所有操作都是主节点完成,然后同步给镜像节点
  • 主宕机后,镜像节点会替代成新的主

若主节点还没给镜像节点同步就宕机了,还是会造成数据丢失

在这里插入图片描述
仲裁队列

仲裁队列:仲裁队列是3.8版本以后才有的新功能,用来替代镜像队列,具备下列特征:

  • 与镜像队列一样,都是主从模式,支持主从数据同步
  • 使用非常简单,没有复杂的配置
  • 主从同步基于Raft协议,强一致

在这里插入图片描述


2、Kafka

2.1 Kafka是如何保证消息不丢失

需要从三个层面去解决这个问题:

  1. 生产者发送消息到Brocker丢失

设置异步发送,发送失败使用回调进行记录或重发
失败重试,参数配置,可以设置重试次数

  1. 消息在Brocker中存储丢失

发送确认acks,选择all,让所有的副本都参与保存数据后确认

  1. 消费者从Brocker接收消息丢失

关闭自动提交偏移量,开启手动提交偏移量
提交方式,最好是同步+异步提交

首先得知道消息在传递过程中经历过哪些阶段:
在这里插入图片描述
所以在生产者、kafka的Brocker、消费者都会出现消息丢失现象

生产者发送消息到Brocker丢失
在这里插入图片描述
解决办法:1、异步发送,发送失败记录日志。2、开启失败重试
在这里插入图片描述
消息在Brocker中存储丢失

在这里插入图片描述
解决办法就是,Brocker收到消息之后,给生产者发送一个ack确认,告诉生产者消息接收到了,至于这个消息是leader发还是leader和follower一起发取决于ack的参数值

在这里插入图片描述
像acks=all 就需要所有的追随者(follower)都同步消息了才会给生产者发送ack确认,效率就很慢,一般设置ack=1,由leader发送确认消息就行了

消费者从Brocker接收消息丢失
在这里插入图片描述
消费者消费消息是根据分区中的偏移量来按位消费

消费者默认是自动按期提交已经消费的偏移量,默认是每隔5s提交一次
如果出现重平衡的情况,可能会重复消费或丢失数据

正常消费:
在这里插入图片描述
重平衡: 会导致消息丢失或者消息重读
消息重读

若此刻consumer2消费消息之后,还没有将偏移量更新同步到分区当中,突然宕机了,此刻consumer1会继承consumer2的分区继续跟着原来的偏移量消费,此刻就会造成重复消费。

在这里插入图片描述
消息丢失

也就是提交偏移量和实际消费的消息有偏差,本来要消费3个,结果只消费了1个,然后偏移量也提交到了3,然后突然宕机了,这个时候别的消费者继承分区之后,会从3之后开始消费,这时候2,3位置的消息就丢失了

在这里插入图片描述

解决办法就是把自动设置偏移量设置为手动

禁用自动提交偏移量,改为手动
同步提交
异步提交
同步+异步组合提交

幂等方案(根据全局唯一id来判断重复提交,或者加分布式锁)

例如:
在这里插入图片描述


2.2 Kafka中消息的重复消费问题如何解决的

参考2.1重平衡,消息重读

  1. 关闭自动提交偏移量,开启手动提交偏移量
  2. 提交方式,最好是同步+异步提交
  3. 幂等方案

2.3 Kafka是如何保证消费的顺序性

问题原因:

一个topic的数据可能存储在不同的分区中,每个分区都有一个按照顺序的存储的偏移量,如果消费者关联了多个分区不能保证顺序性

解决方案:

topic分区中消息只能由消费者组中的唯一一个消费者处理,所以消息肯定是按照先后顺序进行处理的。但是它也仅仅是保证Topic的一个分区顺序处理,不能保证跨分区的消息先后处理顺序。 所以,如果你想要顺序的处理Topic的所有消息,那就只提供一个分区。

发送消息时指定分区号
(主要)发送消息时按照相同的业务设置相同的key

首先得知道kafka默认是不确保消费的顺序性的,因为一个消费者可能负责几个分区,而消费者又是根据偏移量来消费的,不同分区的偏移量自然是不同的

假设用户先充值,再转账,那么必须先充值,才能去转账,这样就要保证消费的顺序性

转账和充值消息在不同分区
在这里插入图片描述
转账和充值消息在同一分区
在这里插入图片描述
这样就能保证转账操作一定是在充值动作的后面执行,也就保证了消费的顺序性

在这里插入图片描述
可以直接指定分区,或者根据key的hashCode来计算分区位置保证需要顺序消费的信息在同一分区


2.4 Kafka的高可用机制有了解过嘛

集群

一个kafka集群由多个broker实例组成,即使某一台宕机,也不耽误其他broker继续对外提供服务

复制机制

一个topic有多个分区,每个分区有多个副本,有一个leader,其余的是follower,副本存储在不同的broker中所有的分区副本的内容是都是相同的,如果leader发生故障时,会自动将其中一个follower提升为leader,保证了系统的容错性、高可用性

集群模式
在这里插入图片描述

  • Kafka 的服务器端由被称为 Broker 的服务进程构成,即一个 Kafka 集群由多个 Broker 组成
  • 这样如果集群中某一台机器宕机其他机器上的 Broker 也依然能够对外提供服务。这其实就是 Kafka 提供高可用的手段之一

分区备份机制
主负责读写,从只负责当做副本,在主宕机了就上去当主
在这里插入图片描述

  • 一个topic有多个分区,每个分区有多个副本,其中有一个leader,其余的是follower,副本存储在不同的broker中
  • 所有的分区副本的内容是都是相同的,如果leader发生故障时,会自动将其中一个follower提升为leader

其实里面的follower从节点也分为两种,一种ISR节点(同步复制),一种普通副本节点(异步复制)
参考本文 2.6

在这里插入图片描述


2.5 解释一下复制机制中的ISR

ISR(in-sync replica)需要同步复制保存的follower
在这里插入图片描述

如果leader失效后,需要选出新的leader,选举的原则如下:

  • 第一:选举时优先从ISR中选定,因为这个列表中follower的数据是与leader同步的
  • 第二:如果ISR列表中的follower都不行了,就只能从其他follower中选取
    在这里插入图片描述

所以ISR类型的节点设置也需要根据实际设置,太多影响效率,太少当主节点宕机可能会出现不够用,
ISR-follower和主节点复制是同步的,数据完整性强,普通follower是异步复制完成的,数据的完整性肯定不如ISR-follower,若都设置为ISR节点,虽然数据完整性强,同步必然导致阻塞,所以只有在ISR节点不够用的情况下,才会去考虑拿普通的节点来充当为主节点


2.6 Kafka数据清理机制了解过嘛

Kafka存储结构

  • Kafka中topic的数据存储在分区上,分区如果文件过大会分段存储segment
  • 每个分段都在磁盘上以索引(xxxx.index)和日志文件(xxxx.log)的形式存储
  • 分段的好处是,第一能够减少单个文件内容的大小,查找数据方便,第二方便kafka进行日志清理。

日志的清理策略有两个:

  • 根据消息的保留时间,当消息保存的时间超过了指定的时间,就会触发清理,默认是168小时( 7天)
  • 根据topic存储的数据大小,当topic所占的日志文件大小大于一定的阈值(默认1G),则开始删除最久的消息。(默认关闭)

首先得知道kafka的数据存储结构

在这里插入图片描述

为什么分段:
删除无用文件方便,提高磁盘利用率
查找数据便捷

文件的命令基本上都是按照偏移量来命名的,查找方便

数据清理机制
在这里插入图片描述

  1. List item

2.7 Kafka中实现高性能的设计有了解过嘛

  1. 消息分区:不受单台服务器的限制,可以不受限的处理更多的数据
    在这里插入图片描述

  2. 顺序读写:磁盘顺序读写,提升读写效率

  3. 页缓存:把磁盘中的数据缓存到内存中,把对磁盘的访问变为对内存的访问(访问内存自然比直接访问磁盘快)

  4. 零拷贝:减少上下文切换及数据拷贝

  5. 消息压缩:减少磁盘IO和网络IO

  6. 分批发送:将消息打包批量发送,减少网络开销

顺序读写:磁盘顺序读写,提升读写效率
在这里插入图片描述

在这里插入图片描述

零拷贝:减少上下文切换及数据拷贝(关键)
一般的消费者去消费的过程包含4次拷贝(因为消费者和生产者一般不处于一个服务器,需要由网卡转发给别的服务器的消费者)
在这里插入图片描述
零拷贝就省略了从页缓存取出数据,由kafka交给网卡转发给消费者,而是直接由页缓存把数据交给网卡,再转交给消费者
在这里插入图片描述

既减少了用户态和内核态的切换(上下文切换)也减少了IO拷贝带来的开销


更新中

参考来自黑马程序员

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小丑西瓜9/article/detail/440198
推荐阅读
相关标签
  

闽ICP备14008679号