消息队列——经典5连问——你能抗几道？

• 面试题1：说说你对消息队列的理解，消息队列为了解决什么问题？
• 追问1：消息队列有什么优缺点
• 面试题2：对于消息中间机，大家是怎么作技术选型的？
• 面试题3：如何确保消息正确地发送至 RabbitMQ？如何确保消息接收方消费了消息？
• 追问1：如何保证MQ消息的可靠传输？

面试题1：说说你对消息队列的理解，消息队列为了解决什么问题？

咱们公司业务系统一开始体量较小，不少组件都是单机版就足够，后来随着用户量逐渐扩大，咱们程序也采用了微服务的设计思想，把不少服务进行了拆分，但后来在一些秒杀抢票活动或高频业务中，服务依旧扛不住大量QPS，所以咱们引入了消息队列来优化该类问题。

消息队列应用的场景大体分为三类：解耦、异步、削峰。

解耦

消息队列相似设计模式中的观察者模式（Observer）或发布-订阅模式（Pub-Sub）。生产者生成和发送消息到消息队列，消费者从消息队列中取走消息进行处理，称为消费，使用消息队列将“生产者”和“消费者”之间的操做关联解耦，易于扩展。

好比系统A为支付系统，一开始用户支付完调用日志记录系统B记录就完了，后来内容愈来愈多，支付完成要调用加积分系统C、短信通知系统D、优惠券系统E等等…

这个场景中，A 系统跟其它各类乱七八糟的系统严重耦合，A 系统产生一条支付成功的数据，不少系统接口都须要 A 系统调用把支付成功的数据发送过去。A 系统程序员要时刻考虑这些问题：

• 其余系统若是挂了该咋办？是否是直接程序抛异常了？
• 一天到晚加业务，每次都从新部署？领导是否是狗？

那若是引入 MQ，A 系统产生一条数据，发送到 MQ 里面去，每一个子系统加上对消息队列中支付成功消息的订阅，持续监听就能够了，哪一个系统须要数据本身去 MQ 里面消费。若是新系统须要数据，直接从 MQ 里消费便可；若是某个系统不须要这条数据了，就取消对 MQ 消息的消费便可。

这样下来，A系统压根儿不须要去考虑要给谁发送数据，不须要维护这个代码，也不须要考虑人家是否调用成功、失败超时等状况，我只负责把支付成功的信息放到MQ里就好了，至于可否正常加积分、可否正常短信通知，管我鸟事！~~可见，经过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统完全解耦了。

面试官：哦，那我听出来了，你这是喜欢甩锅啊！来，简历还你。

数据一致性

这个实际上是分布式服务自己就存在的一个问题，不只仅是消息队列的问题，可是放在这里说是由于用了消息队列这个问题会更明显。

就像我们上面说的，你支付成功的服务本身保证本身的逻辑成功处理了，你成功发了消息，可是短信系统，积分系统等等这么多系统，他们成功仍是失败你就无论了？固然不行，这样坑队友的行为，狄大人都帮不了你~

怎么办？那就把全部的服务都放到一个事务里，全部都成功成功才能算这一次下单是成功的，要成功一块儿成功，要失败一块儿失败。

异步

A 系统接收一个请求，须要在本身本地写库，还须要在 BCD 三个系统写库，本身本地写库要 3ms，BCD 三个系统分别写库要 300ms、400ms、200ms。最终请求总延时是 3 + 300 + 400 + 200 = 903ms，接近 1秒，用户感受搞个毛线？慢的一批。

通常互联网类的企业，对于用户直接的操做，通常要求是每一个请求都必须在 200 ms 之内完成，对用户几乎是无感知的，若是1秒足以说明该系统不可用，垃圾系统。

若是这里使用了消息队列，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感受上就是点个按钮，8ms 之后就直接返回了，体验感很好

削峰

好比咱们系统有代售抢票业务，平时天天QPS也就50左右，A 系统风平浪静。结果每次一到春运抢票，每秒并发请求数量忽然会暴增到10000以上。可是系统是直接基于 MySQL 的，大量的请求直接打到 MySQL，好比通常MySQL能抗2000条请求，如今每秒10000 条 SQL，可能就直接把 MySQL 给打死了，致使系统崩溃。可是高峰期一过就又没人了，QPS回到50，对整个系统几乎没有任何的压力。

若是这里使用 MQ，每秒 1w 个请求写入 MQ，A 系统每秒钟最多处理 2000 个请求，由于 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过本身每秒能处理的最大请求数量就 ok了，这样下来，哪怕是高峰期的时候，A 系统也不会挂掉。固然了，用户的响应时间确定会受影响，毕竟秒杀嘛，只要把前多少条请求处理好，其他的抢票失败就好了。

另外，MQ 每秒钟 1w 个请求进来，只处理 2k 个请求出去，结果会致使在中午高峰期，可能有几十万甚至几百万的请求积压在 MQ 中。

这个短暂的高峰期积压是 ok 的，由于高峰期过了以后，每秒钟就 50 个请求进 MQ，可是A 系统依然会按照每秒 2k 个请求的速度在处理。因此说，只要高峰期一过，A 系统就会快速将积压的消息给消费掉。

追问1：消息队列有什么优缺点

• 系统可用性下降

系统引入的外部依赖越多，越容易挂掉。原本你就是 A 系统调用 BCD 三个系统的接口就行了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？如何保证消息队列的高可用？

• 系统复杂度提升

硬生生加个 MQ 进来，你怎么保证消息必定被消费？如何避免消息重复投递或重复消费？数据丢失怎么办？怎么保证消息传递的顺序性？

• 一致性问题

A 系统处理完了直接返回成功了，人都觉得你这个请求就成功了；可是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

面试题2：对于消息中间机，大家是怎么作技术选型的？

目前市面上比较主流的消息队列中间件主要有，Kafka、ActiveMQ、RabbitMQ、RocketMQ 等。

ActiveMQ和RabbitMQ这两因为吞吐量的缘由，只有业务体量通常的公司在用，RabbitMQ因为是erlang语言开发的，咱们都不了解，所以扩展和维护成本都很高，查个问题都头疼。

Kafka和RocketMQ一直在各自擅长的领域发光发亮，二者的吞吐量、可靠性、时效性等都很可观。

咱们经过图表看看这几个消息中间机的对比：

你们其实一会儿就能看到差距了，就拿吞吐量来讲，早期比较活跃的ActiveMQ 和RabbitMQ基本上不是后二者的对手了，在如今这样大数据的年代吞吐量是真的很重要。

面试题3：如何确保消息正确地发送至 RabbitMQ？如何确保消息接收方消费了消息？

发送方确认模式

将信道设置成confirm模式（发送方确认模式），则全部在信道上发布的消息都会被指派一个惟一的ID。

一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息惟一ID）。

若是RabbitMQ发生内部错误从而致使消息丢失，会发送一条Nack（not acknowledged，未确认）消息。

发送方确认模式是异步的，生产者应用程序在等待确认的同时，能够继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。

接收方确认机制

消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不一样操做）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。

这里并无用到超时机制，RabbitMQ仅经过Consumer的链接中断来确认是否须要从新发送消息。也就是说，只要链接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；

追问1：如何保证MQ消息的可靠传输？

以咱们经常使用的RabbitMQ为例，消息不可靠的状况多是消息丢失，劫持等缘由；

丢失又分为：生产者丢失消息、消息队列丢失消息、消费者丢失消息；

生产者丢失消息：从生产者弄丢数据这个角度来看，RabbitMQ提供confirm模式来确保生产者不丢消息；

confirm模式用的居多：一旦channel进入confirm模式，全部在该信道上发布的消息都将会被指派一个惟一的ID（从1开始），一旦消息被投递到全部匹配的队列以后；RabbitMQ就会发送一个ACK给生产者（包含消息的惟一ID），这就使得生产者知道消息已经正确到达目的队列了；

若是rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你能够进行重试操做。

消息队列丢数据：消息持久化。

处理消息队列丢数据的状况，通常是开启持久化磁盘的配置。

持久化配置和confirm机制配合使用，在消息持久化磁盘后，再给生产者发送一个Ack信号。

这样，若是消息持久化磁盘以前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。

面试官：那你说说如何避免消息重复投递或重复消费？消息是基于什么传输的？
我：今天累了，不想说了，下次吧~
面试官：？？？
我：对了，简历给我来。
面试官：嘶~
我：怎么，玩不起了？

 

累了，不想说了，下次吧~面试官：？？？我：对了，简历给我来。面试官：嘶~我：怎么，玩不起了？