MQ相关面试题

如果你的简历中有写到MQ，那么面试官一般会问到如下几个问题，至少我在面试中经常常被问到，所以今天总结一下，有不对的地方还望多多包涵：

首先第一个问题，为什么要用MQ？

如果这个问题你都没考虑过，那么说明你只是一个单纯会用MQ技术的一个coder，而不是一个会独立思考的程序员，如果被面试官问到这个问题，你都没有回答上来，那么你的第一印象肯定会很差。

一、为什么要用MQ？

（1）解耦：如果多个模块或者系统中，互相调用很复杂，维护起来比较麻烦，但是这个调用又不是同步调用，就可以运用MQ到这个业务中。

（2）异步：这个很好理解，比如用户的操作日志的维护，可以不用同步处理，节约响应时间。

（3）削峰：在高峰期的时候，系统每秒的请求量达到 5000，那么调用 MySQL 的请求也是 5000，一般情况下 MySQL 的请求大概在 2000 左右，那么在高峰期的时候，数据库就被打垮了，那系统就不可用了。此时引入MQ，在系统 A 前面加个 MQ，用户请求先到 MQ，系统 A 从 MQ 中每秒消费 2000 条数据，这样就把本来 5000 的请求变为 MySQL 可以接受的请求数量了，可以保证系统不挂掉，可以继续提供服务。MQ 里的数据可以慢慢的把它消费掉。

二、使用了MQ会有什么问题？

这个问题记住一个降低一个增加即可。

（1）降低了系统可用性 （2）增加了系统的复杂性

三、怎样选型MQ？

如果你被问及这个问题，面试官主要是想看你选型的时候是否会比较架构的区别，是否满足业务需求。

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级	万级	十万级	十万级
topic 数量对吞吐量的影响	-	-	topic 可以达到几百，几千个的级别，吞吐量会有较小幅度的下降	topic 从几十个到几百个的时候，吞吐量会大幅度下降
时效性	毫秒级	微妙级	毫秒级	毫秒级
可用性	高	高	非常高，分布式架构	非常高，分布式架构
消息可靠性	有较低的概率丢失数据	-	经过参数优化配置，可以做到 0 丢失	经过参数优化配置，消息可以做到 0 丢失
功能支持	完善	并发能力很强，性能极其好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准
优劣势总结	非常成熟，功能强大；偶尔会有较低概率丢失消息；社区不活跃了	性能极其好，延时很低；功能完善；提供管理界面；社区比较活跃；吞吐量较低；使用 erlang 开发源码阅读不方便；	接口简单易用；吞吐量高；分布式扩展方便；社区还算活跃；经过双 11 的考验	MQ 功能比较少；吞吐量高；分布式架构；可能存在消息重复消费问题；主要适用大数据实时计算以及日志收集；

 个人建议：

中小型公司，技术一般，可以考虑用 RabbitMQ；
大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择
实时计算、日志采集：使用 kafka；

四、怎样保证MQ的高可用？

RabbitMQ是比较有代表性的，因为是基于主从做高可用性的。以他为例，自行查阅以下模式。

rabbitmq有三种模式：单机模式、普通集群模式、镜像集群模式。

五、如何保证不被重复消费？

不通的消费队列都会有一个消费通知的机制，如：

RabbitMQ提供了一个ACK确认消息机制，

rocketMQ返回一个CONSUME_SUCCESS成功标志

 (1)比如，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
 (2)再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
 (3)如果上面两种情况还不行，上大招。准备一个第三方介质,来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis。那消费者开始消费前，先去redis中查询有没消费记录即可。

六、如何保证消费的可靠传输性？

 

每个MQ都要从生产者丢失数据、消费队列丢失数据、消费丢失数据三个层面回答

(1) 生产者丢失数据

以rabbitMQ为例，rabbitMQ提供了transaction和confirm模式来确保生产者不丢失数据，事务机制，发送消息前，开启事务（channel.txSelect()）,发送消息后出现异常，事务回滚（channel.txRollback()）,发送成功提交事务（channel.txCommit()）。

上面这种方式吞吐量会下降，因此生产上应该使用confirm模式居多。

一旦channel进入confirm模式，所有在该通道发布上的消息都会被指派一个唯一的ID（从1开始），消息进来如队列后，rabbitMq会立即发送一个ACK给生产者，其中包含了消息的唯一ID，这就使得生产者知道消息已经到达了消息队列里。如果消息队列没能处理该消息，则会发送一个NACK给生产者进行重试操作。

channel.addConfirmListener(new ConfirmListener() {

    @Override
    public void handleNack(long deliveryTag, boolean multiple) throws IOException {
        System.out.println("nack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
    }

    @Override
    public void handleAck(long deliveryTag, boolean multiple) throws IOException {
        System.out.println("ack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
    }
});

(2) 消息队列丢失数据

消息队列丢失的情况一般是开启持久化硬盘配置，这个持久化配置可以和confirm机制配合使用，可以在持久化硬盘之后，发送一个ack给生产者，如果生产者收不到ack信息，会重发信息。

如何持久化硬盘：

①将queue的持久化标识durable设置为true，

②发送消息的时候将deliveryMode=2

这样设置就算rabbitMQ挂了，重启后也能恢复数据

(3) 消费者丢失数据

消费者丢失数据一般都是以为采用了自动确认消息模式。消费者收到消息后，rabbitMQ会立即从队列里面删除该消息，这是情况如果消费者出现异常而没有及时处理该消息就会丢失数据。

解决方案：采用手动确认消息。

 七、如何保证消息的时序性？

先进先出队列，比如linkedBlockingQueue。