【面试】MQ常见面试问题
简介
·现在java分布式项目中，MQ基本都是必备的消息中间件。或许你曾接触过RabbitMQ,RocketMQ,Kafka,ActiveMQ。或许你只是对这些有所耳闻。今天，简单总结一下关于MQ在面试的一些问题。
什么是消息队列
·首先，我们聚焦在队列上。我们都知道队列是一种数据结构，支持先进先出。所以，消息队列就是一种可以储存消息的容器，当我们需要使用消息的时候可以取出消息供自己使用。并且是有顺序的。当生产者按照A,B,C·这样的顺序存入消息队列中，消费者也按照A,B,C…这样的顺序取出来进行消费。
·消息队列是分布式中的消息中间件。使用它，主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。虽然我们引入消息队列存在这些优点，但当一个系统加入一个新东西时，必然会带来一些问题。例如消费的顺序性，如何保证消息不被重复消费?如何保证消息的可靠性传输《如何处理消息丢失的问题)?…等等问题。所以说使用消息队列也不是十全十美的，使用它也会让系统可用性降
低、复杂度提高，另外还需要我们保障一致性等问题。
·目前流行的MQ就有RabbitMQ,RocketMQ,Kafka,ActiveMQ。各种MQ都有其对应的使用场景，等下在后面也会——对比这些消息队列。
为什么要使用消息队列
总体而言，使用消息队列有两点好处。
1.通过异步处理提高系统性能(削峰、减少响应所需时间);
2.降低系统耦合性。
(1)通过异步处理提高系统性能(削峰、减少响应所需时间);
●如上图中，在不使用消息队列服务器的时候，用户的请求数据直接写入数据库，在高并发的情况下数据库压力剧增，使得响应速度变慢。但是在使用消息队列之后，用户的请求数据发送给消息队列之后立即返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。
·由于消息队列服务器处理速度快于数据库(消息队列也比数据库有更好的伸缩性),因此响应速度得到大幅改善。
·消息队列具有很好的削峰作用的功能—即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。举例：在电子商务一些秒杀、促销活动中，合理使用消息队列可以有效抵御促销活动刚开始大量订单涌入对系统的冲击。如下图所示：
●用户请求数据写入消息队列之后就立即返回给用户了，但是请求数据在后续的业务校验、写数据库等操作中可能失败。因此使用消息队列进行异步处理之后，需要适当修改业务流程进行配合，
·比如用户在提交订单之后，订单数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功，以免交易纠纷。这就类似我们平时手机订火车票和电影票。
(2)降低系统耦合性。我们知道如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展性无疑更好一些。
我们最常见的事件驱动架构类似生产者消费者模式，在大型网站中通常用利用消息队列实现事件驱动结构。如下图所示；
应用程序B
(消息接收者)
应用程序A
(消息发送者)
应用程序C《消息接收者)
分布式消息队列
消息队列使利用发布-订阅模式工作，消息发送者(生产者)发布消息，一个或多个消息接受者(消费者)订阅消息。从上图可以看到消息发送者(生产者)和消息接受者(消费者)之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响。从而实现网站业务的可扩展性设计。
消息接受者对消息进行过滤、处理、包装后，构造成一个新的消息类型，将消息继续发送出去，等待其他消息接受者订阅该消息。因此基于事件(消息对象)驱动的业务架构可以是一系列流程。
另外为了避免消息队列服务器宕机造成消息丢失，会将成功发送到消息队列的消息存储在消息生产者服务器上，等消息真正被消费者服务器处理后才删除消息。在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中的其他服务器发布消息。
备注：消息队列只能利用发布-订阅模式工作，只不过在解耦这个特定业务环境下是使用发布-订阅模式的。除了发布-订阅模式，还有点对点订阅模式(一个消息只有一个消费者),我们比较常用的是发布-订阅模式。另外，这两种消息模型是JMS提供的，AMQP协议还提供了5种消息模型。
消息队列可能带来的问题
·系统可用性降低；系统可用性在某种程度上降低，为什么这样说呢?在加入MQ之前，你不用考虑消息丢失或者说MQ