黑马Java面试教程_P6_消息中间件

原创于 2025-03-05 23:02:53 发布 · 807 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#java #面试 #开发语言

面试专栏收录该内容

35 篇文章

订阅专栏

系列博客目录

1.引言

目前的项目中比较常见，第一个是他提供了系统之间的异步调用，让服务与服务之间解耦，第二个是还可以做到削峰填谷。目前市面上消息中间件很多，主要讲下面两个。
简单的在文稿中，不在视频中讲解。
在这里插入图片描述

2.RabbitMQ

2.1 RabbitMQ如何保证消息不丢失？

RabbitMQ的作用如下：
在这里插入图片描述

上面都有可能导致消息丢失。第一个是消息未到达交换机或者队列，第二个是MQ宕机导致，第三个是消费者宕机导致（未接收到消息或者未处理消息）。
一下是针对这三种情况。

第一种：消息未到达交换机或者队列
在这里插入图片描述
那如果再失败呢？一般消息发送失败都是publisher宕机，一般不会一直宕机，如果一直宕机或者失败，只能交给人工。

第二种：如果MQ可能会宕机的话，如下
在这里插入图片描述

第三种：消费者宕机导致
在这里插入图片描述

在这里插入图片描述

面试文稿

RabbitMQ如何保证消息不丢失？
候选人：
我们使用RabbitMQ来确保MySQL和Redis间数据双写的一致性，这要求我们实现消息的高可用性，具体措施包括：
1. 开启生产者确认机制，确保消息能被送达队列，如有错误则记录日志并修复数据。
2. 启用持久化功能，保证消息在未消费前不会在队列中丢失，需要对交换机、队列和消息本身都进行持久化。
3. 对消费者开启自动确认机制，并设置重试次数。例如，我们设置了3次重试，若失败则将消息发送至异常交换机，由人工处理。

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

在这里插入图片描述
在消费者进行自动确认时，发生网络抖动或者消费者挂了。那如果一条消息已经被消费者处理，但是没有被确认，他还是会再次被处理。

解决方案如下：
在这里插入图片描述
第一个方案是，在处理消息时，查看业务id是否存在，如果已经存在，说明数据库中已经有了消息所包含的内容，防止重复处理。
这两个方法，适用于任何MQ。

面试文稿

RabbitMQ消息的重复消费问题如何解决？
候选人：
我们遇到过消息重复消费的问题，处理方法是：
- 设置消费者为自动确认模式，如果服务在确认前宕机，重启后可能会再次消费同一消息。
- 通过业务唯一标识检查数据库中数据是否存在，若不存在则处理消息，若存在则忽略，避免重复消费。
那你还知道其他的解决方案吗？
候选人：
是的，这属于幂等性问题，可以通过以下方法解决：
- 使用Redis分布式锁或数据库锁来确保操作的幂等性。

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

延迟队列:进入队列的消息会被延迟消费的队列
场景:超时订单、限时优惠、定时发布
延迟队列=死信交换机+TTL(生存时间)
在这里插入图片描述

在这里插入图片描述

上面两种时间哪种短，就以哪种为主。

在这里插入图片描述

面试文稿

RabbitMQ中死信交换机了解吗？（RabbitMQ延迟队列有了解过吗？）
候选人：
了解。我们项目中使用RabbitMQ实现延迟队列，主要通过死信交换机和TTL（消息存活时间）来实现。
- 消息若超时未消费则变为死信，队列可绑定死信交换机，实现延迟功能。
- 另一种方法是安装RabbitMQ的死信插件，简化配置，在声明交换机时指定为死信交换机，并设置消息超时时间。

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

在这里插入图片描述

面试文稿

如果有100万消息堆积在MQ，如何解决？
候选人：
若出现消息堆积，可采取以下措施：
1. 提高消费者消费能力，如使用多线程。
2. 增加消费者数量，采用工作队列模式，让多个消费者并行消费同一队列。
3. 扩大队列容量，使用RabbitMQ的惰性队列，支持数百万条消息存储，直接存盘而非内存。

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

在生产环境下，使用集群来保证高可用性（其实很多技术都可以使用集群）
普通集群、镜像集群、仲裁队列

在这里插入图片描述因为上面第三点，所以这种集群并不好用。

上面的节点表述的是一个橘色块中的队列。
还是存在一个问题，如果主节点的队列还没来得及给镜像节点同步数据，这时候主节点就宕机了，那是不是说数据还没有同步完成，就有可能丢失数据，虽然发生概率低。可以用仲裁队列来解决。
在这里插入图片描述

面试文稿

RabbitMQ的高可用机制了解吗？
候选人：
我们项目在生产环境使用RabbitMQ集群，采用镜像队列模式，一主多从结构。
- 主节点处理所有操作并同步给从节点，若主节点宕机，从节点可接替为主节点，但需注意数据同步的完整性。
那出现丢数据怎么解决呢？
候选人：
使用仲裁队列，主从模式，基于Raft协议实现强一致性数据同步，简化配置，提高数据安全性。

3 Kafka

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

在这里插入图片描述

面试文稿

Kafka是如何保证消息不丢失？
候选人：
Kafka保证消息不丢失的措施包括：
1. 生产者使用异步回调发送消息，设置重试机制应对网络问题。
2. 在Broker中通过复制机制，设置acks参数为all，确保消息在所有副本中都得到确认。
3. 消费者手动提交消费成功的offset，避免自动提交可能导致的数据丢失或重复消费。
Kafka中消息的重复消费问题如何解决？
候选人：
通过以下方法解决Kafka中的重复消费问题：
- 禁用自动提交offset，手动控制offset提交时机。
- 确保消息消费的幂等性，例如通过唯一主键或分布式锁。

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

在这里插入图片描述

面试文稿

Kafka是如何保证消费的顺序性？
候选人：
Kafka默认不保证消息顺序性，但可以通过以下方法实现：
- 将消息存储在同一个分区，通过指定分区号或相同的业务key来实现。

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

在这里插入图片描述

面试文稿

Kafka的高可用机制了解吗？
候选人：
Kafka的高可用性主要通过以下机制实现：
- 集群部署，多broker实例，单点故障不影响整体服务。
- 复制机制，每个分区有多个副本，leader和follower，leader故障时从follower中选举新leader。
解释一下复制机制中的ISR？
候选人：
ISR（In-Sync Replicas）指与leader保持同步的follower副本。
- 当leader故障时，优先从ISR中选举新leader，因为它们数据一致性更高。