现在是各个软件开发相关企业的招人高峰期，消息队列也是高频发的面试题目，所以我们今天精心的准备了有关消息队列经常提及到的面试题以及答案的梳理，希望能给正在求职的人提供帮助。

1. 为什么使用消息队列?消息队列优缺点?

优点：解耦、异步、削峰

解耦场景：

不用消息队列场景：假设A系统需要调用B、C系统，后来又需要增加调用D系统或者不需要调用B系统时候，这种会需要频繁修改A系统代码，A系统还得考虑调用的系统挂了或者超时怎么办，要不要做重试机制

用消息队列，只需要A把数据发送到消息队列，哪个系统需要自己去取就行了

缺点：系统高可用性降低：比如MQ一旦故障，整个系统就崩溃了

系统复杂性增加：要考虑重复数据、丢数据、数据顺序不一致等问题

一致性问题：A系统处理完请求直接返回成功了，BCD系统接收消息，但是BC消费成功，D一直消费不成功，这个时候数据就不一致了

2.rabbitmq、kafka、activemq、rocketmq之间区别?

activemq比较成熟，有较低概率丢数据吞吐量低，用异步和解耦可以用下。

rabbitmq吞吐量万级，只比kafka低些，消息时效性最低，微秒级别，基本不丢数据。

rocketmq吞吐量10万级，比rabbitmq高些，消息时效性ms级别

kafka吞吐量10万级，吞吐量最高，常用于大数据，日志分析

3.如何保证消息队列高可用性?

rabbitmq镜像集群模式：创建的queue，无论元数据还是queue消息都会存在多个服务器节点上，每次写queue消息都会同步到其他节点上，好处在任何一个节点宕机了还有其他节点可用，不会导致系统也挂掉，坏处在于网络带宽压力大，没什么扩展性而言。怎么开启镜像模式?rabbitmq管理后台有个镜像集群策略，创建queue的时候应用这个策略就行。

kafka集群模式：服务器可以多个leader服务器组成集群，每个leader服务器下有可以有多个副本备份服务器，生产者只能往leader服务器写数据，消费者也只能从leader服务器读服务器。

2. 4.消费了重复数据怎么解决?(其实就是问如何保证幂等性)

会产出消费重复数据原因：生成者发送了123三条数据，消费者消费12数据 整备提交给生成者说我已消费，但还没提交时候消费者服务器挂了重启，生成者未接收到消费者已消费的消息，于是生成者又发送了123三条数据，就导致了重复消费。

解决：如果是插入数据库，每次插入之前先根据主键id去数据库查下，如果有数据就update，如果是插入redis，那把主键id set保存，天然幂等性。如果上面两种情况，那在里面加个全局唯一的id，消费到了后先去redis中去查下，如果消费掉了就处理掉。

5。如何保证消息传输的可靠性?(如何处理消息丢失的问题)

丢失原因：1)生产者消息在传给rabbitmq过程中因为网络原因丢失了

2)rabbitmq把消息存在内存中时rabbitmq挂掉了。

生产者丢失解决：1)rabbitmq支持事务，如果消费者没返回消费成功的消息，生产 者会重试发送这条消息。因为是同步机制会导致吞吐量下降。

2)生成者channel(通道)调成confirm模式，发送一个消息，rabbitmq如果接受到这条消息或接收这条消息失败了，会回调本地接口，通知你我已接收到了或者失败了然后重新通知你重新发送

rabbitmq丢失解决:开启rabbitmq持久化(消息写入后持久化)，创建queue也开启持久化(消息元数据持久化),在发送消息时候将消息的deliveryMode设置为2(消息持久化)。

消费者丢失解决：关掉消费者的autoAck机制。

6.如何保证消息按顺序执行?

造成原因：生产者123三条数据发送给三个消费者，本来应该按照123顺序消费，但是应为2数据最先接收到消费了，导致消费顺序错乱了。

解决：queue单对单模式，把123数据给一个queue，发送给一个消费者执行。

7.几百万消息积压? 消息队列延时及过期失效问题? 积压原因：消费者故障导致不能消费消息

解决：临时紧急扩容消费者

...

以上都是消息队列重要的面试题，希望各位都能找到自己心仪的工作!想了解更多的相关问题记得关注本站消息。