如果你的简历中有写到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。