90%的Java程序员，都扛不住这波消息中间件的面试四连炮！

本文来自公众号读者jianfeng的投稿

---------------------------------------

概述

你们平时也有用到一些消息中间件(MQ)，可是对其理解可能仅停留在会使用API能实现生产消息、消费消息就完事了。

对MQ更加深刻的问题，可能不少人没怎么思考过。

好比，你跳槽面试时，若是面试官看到你简历上写了，熟练掌握消息中间件，那么极可能给你发起以下 4 个面试连环炮！

• 为何要使用MQ？

• 使用了MQ以后有什么优缺点？

• 怎么保证MQ消息不丢失？

• 怎么保证MQ的高可用性？

本文将经过一些场景，配合着通俗易懂的语言和多张手绘彩图，讨论一下这些问题。

为何要使用MQ？

相信你们也听过这样的一句话：好的架构不是设计出来的，是演进出来的。

这句话在引入MQ的场景一样适用，使用MQ一定有其道理，是用来解决实际问题的。而不是看见别人用了，我也用着玩儿一下。

其实使用MQ的场景有挺多的，可是比较核心的有3个：

异步、解耦、削峰填谷

异步

咱们经过实际案例说明：假设A系统接收一个请求，须要在本身本地写库执行SQL，而后须要调用BCD三个系统的接口。

假设本身本地写库要3ms，调用BCD三个系统分别要300ms、450ms、200ms。

那么最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，可能用户会感受太慢了。

此时整个系统大概是这样的：

可是一旦使用了MQ以后，系统A只须要发送3条消息到MQ中的3个消息队列，而后就返回给用户了。

假设发送消息到MQ中耗时20ms，那么用户感知到这个接口的耗时仅仅是20 + 3 = 23ms，用户几乎无感知，倍儿爽！

此时整个系统结构大概是这样的：

能够看到，经过MQ的异步功能，能够大大提升接口的性能。

解耦

假设A系统在用户发生某个操做的时候，须要把用户提交的数据同时推送到B、C两个系统的时候。

这个时候负责A系统的哥们想：没事啊，B、C两个系统给我提供一个Http接口或者RPC接口，我把数据推送过去不就完事了吗。负责A系统的哥们美滋滋。

以下图所示：

一切看起来很美好，可是随着业务快速迭代，这个时候系统D也想要这个数据。那既然这样，A系统的开发同窗就改咯，在发送数据给BC的同时加上一个D。

可是，越到后面愈加现，麻烦来了。。。

整个系统好像不止这个数据要发送给BCD、还有第2、第三个数据要发送给BCD。甚至有时候又加入了E、F等等系统，他们也要这个数据。

而且有时候可能B系统忽然又不要这个数据了，A系统该来改去，A系统的开发哥们头皮发麻。

更复杂的场景是，数据经过接口传给其余系统有时候还要考虑重试、超时等一些异常状况，真是头发都白了呀。。。

来看下图，体会一下这无助的现场：

这个时候，就该咱们的MQ粉墨登场了！

这种状况下使用MQ来解耦是在合适不过了，由于负责A系统的哥们只须要把消息扔到MQ就好了，其余系统按需来订阅消息就行了。

就算某个系统不须要这个数据了，也不会须要A系统改动代码。

看看加入MQ解耦的下图，是否是清爽了不少！

削峰填谷

举个例子，好比咱们的订单系统，在下单的时候就会往数据库写数据。可是数据库只能支撑每秒1000左右的并发写入，并发量再高就容易宕机。

低峰期的时候并发也就100多个，可是在高峰期时候，并发量会忽然激增到5000以上，这个时候数据库确定死了。

以下图，来感觉一下数据库被打死的绝望：

可是使用了MQ以后，状况就变了！

消息被MQ保存起来了，而后系统就能够按照本身的消费能力来消费，好比每秒1000个数据，这样慢慢写入数据库，这样就不会打死数据库了：

整个过程，以下图所示：

至于为何叫作削峰填谷呢?来看看这个图：

若是没有用MQ的状况下，并发量高峰期的时候是有一个“顶峰”的，而后高峰期事后又是一个低并发的“谷”。

可是使用了MQ以后，限制消费消息的速度为1000，可是这样一来，高峰期产生的数据势必会被积压在MQ中，高峰就被“削”掉了。

可是由于消息积压，在高峰期事后的一段时间内，消费消息的速度仍是会维持在1000QPS，直到消费完积压的消息,这就叫作“填谷”

经过上面的分析，你们就能够知道为何要使用MQ，以及使用了MQ有什么好处。知其因此然，明白了本身的系统为何要使用MQ。

这样之后别人问你为啥要用MQ，就不会出现 “咱们组长要用MQ咱们就用了” 这样尴尬的回答了。

使用了MQ以后有什么优缺点？

看到这个问题蒙圈了，用了就用了嘛！优势上面已经说了，可是这个缺点是啥啊。好像没啥缺点啊。

若是你这样想，就大错特错了，在设计系统的过程当中，除了要清楚的知道为何要用这个东西，还要思考一下用了以后有什么坏处。这样才能内心有底，防范于未然。

接下来咱们就讨论一下，用MQ会有什么缺点把？

系统可用性下降

你们想一想一下，上面的说解耦的场景，原本A系统的哥们要把系统关键数据发送给BC系统的，如今忽然加入了一个MQ了，如今BC系统接收数据要经过MQ来接收。

可是你们有没有考虑过一个问题，万一MQ挂了怎么办？这就引出一个问题，加入了MQ以后，系统的可用性是否是就下降了？

由于多了一个风险因素：MQ可能会挂掉。只要MQ挂了，数据没了，系统运行就不对了。

系统复杂度提升

原本个人系统经过接口调用一下就能完事的，可是加入一个MQ以后，须要考虑消息重复消费、消息丢失、甚至消息顺序性的问题

为了解决这些问题，又须要引入不少复杂的机制，这样一来是否是系统的复杂度提升了。

数据一致性问题

原本好好的，A系统调用BC系统接口，若是BC系统出错了，会抛出异常，返回给A系统让A系统知道，这样的话就能够作回滚操做了

可是使用了MQ以后，A系统发送完消息就完事了，认为成功了。而恰好C系统写数据库的时候失败了，可是A认为C已经成功了？这样一来数据就不一致了。

经过分析引入MQ的优缺点以后，就明白了使用MQ有不少优势，可是会发现它带来的缺点又会须要你作各类额外的系统设计来弥补

最后你可能会发现整个系统复杂了好几倍，因此设计系统的时候要基于这些考虑作出取舍，不少时候你会发现该用的仍是要用的。。。

怎么保证MQ消息不丢失？

使用了MQ以后，还要关心消息丢失的问题。这里咱们挑RabbitMQ来讲明一下吧。

生产者弄丢了数据

RabbitMQ生产者将数据发送到rabbitmq的时候,可能数据在网络传输中搞丢了，这个时候RabbitMQ收不到消息，消息就丢了。

RabbitMQ提供了两种方式来解决这个问题：

事务方式：

在生产者发送消息以前，经过`channel.txSelect`开启一个事务，接着发送消息

若是消息没有成功被RabbitMQ接收到，生产者会收到异常，此时就能够进行事务回滚`channel.txRollback`而后从新发送。假如RabbitMQ收到了这个消息，就能够提交事务`channel.txCommit`。

可是这样一来，生产者的吞吐量和性能都会下降不少，如今通常不这么干。

另一种方式就是经过confirm机制：

这个confirm模式是在生产者哪里设置的，就是每次写消息的时候会分配一个惟一的id，而后RabbitMQ收到以后会回传一个ack，告诉生产者这个消息ok了。

若是rabbitmq没有处理到这个消息，那么就回调一个nack的接口，这个时候生产者就能够重发。

事务机制和cnofirm机制最大的不一样在于事务机制是同步的，提交一个事务以后会阻塞在那儿

可是confirm机制是异步的，发送一个消息以后就能够发送下一个消息，而后那个消息rabbitmq接收了以后会异步回调你一个接口通知你这个消息接收到了。

因此通常在生产者这块避免数据丢失，都是用confirm机制的。

Rabbitmq弄丢了数据

RabbitMQ集群也会弄丢消息，这个问题在官方文档的教程中也提到过，就是说在消息发送到RabbitMQ以后，默认是没有落地磁盘的，万一RabbitMQ宕机了，这个时候消息就丢失了。

因此为了解决这个问题，RabbitMQ提供了一个持久化的机制，消息写入以后会持久化到磁盘

这样哪怕是宕机了，恢复以后也会自动恢复以前存储的数据，这样的机制能够确保消息不会丢失。

设置持久化有两个步骤：

• 第一个是建立queue的时候将其设置为持久化的，这样就能够保证rabbitmq持久化queue的元数据，可是不会持久化queue里的数据

• 第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。

可是这样一来可能会有人说：万一消息发送到RabbitMQ以后，还没来得及持久化到磁盘就挂掉了，数据也丢失了，怎么办？

对于这个问题，实际上是配合上面的confirm机制一块儿来保证的，就是在消息持久化到磁盘以后才会给生产者发送ack消息。

万一真的遇到了那种极端的状况，生产者是能够感知到的，此时生产者能够经过重试发送消息给别的RabbitMQ节点

消费端弄丢了数据

RabbitMQ消费端弄丢了数据的状况是这样的：在消费消息的时候，刚拿到消息，结果进程挂了，这个时候RabbitMQ就会认为你已经消费成功了，这条数据就丢了。

对于这个问题，要先说明一下RabbitMQ消费消息的机制：在消费者收到消息的时候，会发送一个ack给RabbitMQ，告诉RabbitMQ这条消息被消费到了，这样RabbitMQ就会把消息删除。

可是默认状况下这个发送ack的操做是自动提交的，也就是说消费者一收到这个消息就会自动返回ack给RabbitMQ，因此会出现丢消息的问题。

因此针对这个问题的解决方案就是：关闭RabbitMQ消费者的自动提交ack,在消费者处理完这条消息以后再手动提交ack。

这样即便遇到了上面的状况，RabbitMQ也不会把这条消息删除，会在你程序重启以后，从新下发这条消息过来。

怎么保证MQ的高可用性性？

使用了MQ以后，咱们确定是但愿MQ有高可用特性，由于不可能接受机器宕机了，就没法收发消息的状况。

这一块咱们也是基于RabbitMQ这种经典的MQ来讲明一下：

RabbitMQ是比较有表明性的，由于是基于主从作高可用性的，咱们就以他为例子讲解第一种MQ的高可用性怎么实现。

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

单机模式

单机模式就是demo级别的，就是说只有一台机器部署了一个RabbitMQ程序。

这个会存在单点问题，宕机就玩完了，没什么高可用性可言。通常就是你本地启动了玩玩儿的，没人生产用单机模式。

普通集群模式

这个模式的意思就是在多台机器上启动多个rabbitmq实例。相似的master-slave模式同样。

可是建立的queue，只会放在一个master rabbtimq实例上，其余实例都同步那个接收消息的RabbitMQ元数据。

在消费消息的时候，若是你链接到的RabbitMQ实例不是存放Queue数据的实例，这个时候RabbitMQ就会从存放Queue数据的实例上拉去数据，而后返回给客户端。

总的来讲，这种方式有点麻烦，没有作到真正的分布式，每次消费者链接一个实例后拉取数据，若是链接到不是存放queue数据的实例，这个时候会形成额外的性能开销。若是从放Queue的实例拉取，会致使单实例性能瓶颈。

若是放queue的实例宕机了，会致使其余实例没法拉取数据，这个集群都没法消费消息了，没有作到真正的高可用。

因此这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提升吞吐量的，就是说让集群中多个节点来服务某个queue的读写操做。

镜像集群模式

镜像集群模式才是真正的rabbitmq的高可用模式，跟普通集群模式不同的是：建立的queue不管元数据仍是queue里的消息都会存在于多个实例上，

每次写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

这样的话任何一个机器宕机了别的实例均可以用提供服务，这样就作到了真正的高可用了。

可是也存在着很差之处：

• 性能开销太高，消息须要同步全部机器，会致使网络带宽压力和消耗很重

• 扩展性低：没法解决某个queue数据量特别大的状况，致使queue没法线性拓展。

  就算加了机器，那个机器也会包含queue的全部数据，queue的数据没有作到分布式存储。

对于RabbitMQ的高可用通常的作法都是开启镜像集群模式，这样起码来讲作到了高可用，一个节点宕机了，其余节点能够继续提供服务。

总结

经过本篇文章，分析了对于MQ的一些常规问题：

• 为何使用MQ？

• 使用MQ有什么优缺点

• 如何保证消息不丢失？

• 如何保证MQ高可用性？

可是，这些问题仅仅是使用MQ的其中一部分须要考虑的问题，事实上，还有其余更加复杂的问题须要咱们去解决，

好比：如何保证消息的顺序性？消息队列如何选型？消息积压问题如何解决?

本文仅仅是针对RabbitMQ的场景举例子。还有其余比较的消息队列，好比RocketMQ、Kafka

不一样的MQ在面临上述问题的时候，要根据他们的原理机制来作对应的处理，这些都是本文没有顾及的内容，将在后面的文章中讨论。敬请关注。

End

推荐一个专栏：

《从零开始带你成为JVM实战高手》

做者是我多年好友，之前团队的左膀右臂

一块儿经历过各类大型复杂系统上线的血雨腥风

现任阿里资深技术专家，对JVM有丰富的生产实践经验

专栏目录参见文末，能够扫下方海报进行试读

经过上面海报购买，再返你24元

领取方式：加微信号：Giotto1245，暗号：返现