Java高频面试题- 每日三连问？【Day8】 — 消息队列篇

问题导读

一、说说你对消息队列的理解，消息队列为了解决什么问题？

二、消息队列有什么优缺点？

三、说一下RabbitMQ有哪些工作模式？

 

一、说说你对消息队列的理解，消息队列为了解决什么问题？

正经回答：

我们公司业务系统一开始体量较小，很多组件都是单机版就足够，后来随着用户量逐渐扩大，我们程序也采用了微服务的设计思想。

把很多服务进行了拆分，但后来在一些秒杀抢票活动或高频业务中，服务依旧扛不住大量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 系统就跟其它系统彻底解耦了。

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

我：额。。不，我开玩笑的，当然不能这样做，这里其实涉及到MQ在分布式事务中数据一致性的问题；听我跟您解释。

数据一致性

这个其实是分布式服务本身就存在的一个问题，不仅仅是消息队列的问题，但是放在这里说是因为用了消息队列这个问题会更明显。

就像咱们上面说的，你支付成功的服务自己保证自己的逻辑成功处理了，你成功发了消息，但是短信系统，积分系统等等这么多系统，他们成功还是失败你就不管了？当然不行，这样坑队友的行为，狄大人都帮不了你~

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

异步

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 系统就会快速将积压的消息给消费掉。

 

二、消息队列有什么优缺点？

正经回答：

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。

缺点有以下几个：

系统可用性降低

本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性会降低；

系统复杂度提高

加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。

因此，需要考虑的东西更多，复杂性增大。

一致性问题

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

所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。

 

三、说一下RabbitMQ有哪些工作模式？

正经回答：

一.simple模式（即最简单的收发模式）

1.消息产生消息，将消息放入队列

2.消息的消费者(consumer) 监听 消息队列,如果队列中有消息,就消费掉,消息被拿走后,自动从队列中删除(隐患 消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失，这里可以设置成手动的ack,但如果设置成手动ack，处理完后要及时发送ack消息给队列，否则会造成内存溢出)。

二.work工作模式(资源的竞争)

1.消息产生者将消息放入队列消费者可以有多个,消费者1,消费者2同时监听同一个队列,消息被消费。C1 C2共同争抢当前的消息队列内容,谁先拿到谁负责消费消息(隐患：高并发情况下,默认会产生某一个消息被多个消费者共同使用,可以设置一个开关(syncronize) 保证一条消息只能被一个消费者使用)。

三.publish/subscribe发布订阅(共享资源)

1、每个消费者监听自己的队列；

2、生产者将消息发给broker，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的队列都将接收到消息。

四.routing路由模式

1.消息生产者将消息发送给交换机按照路由判断,路由是字符串(info) 当前产生的消息携带路由字符(对象的方法),交换机根据路由的key,只能匹配上路由key对应的消息队列,对应的消费者才能消费消息;

2.根据业务功能定义路由字符串

3.从系统的代码逻辑中获取对应的功能字符串,将消息任务扔到对应的队列中。

4.业务场景:error 通知;EXCEPTION;错误通知的功能;传统意义的错误通知;客户通知;利用key路由,可以将程序中的错误封装成消息传入到消息队列中,开发者可以自定义消费者,实时接收错误;

五.topic 主题模式(路由模式的一种)

1.星号井号代表通配符

2.星号代表多个单词,井号代表一个单词

3.路由功能添加模糊匹配

4.消息产生者产生消息,把消息交给交换机

5.交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费

（在我的理解看来就是routing查询的一种模糊匹配，就类似sql的模糊查询方式）

每日小结

今天我们复习了面试中常考的消息队列三个问题，你做到心中有数了么？

对了，**如果你的朋友也在准备面试，请将这个系列扔给他，如果他认真对待，肯定会感谢你的！！**

 好了，今天就到这里，学废了的同学，`记得三连，也会给我继续更新的动力。`

另外，我在公众号中为大家准备了[ 大厂技术资源 | 研发必备安装包 | 经典必读电子书 | 限时免费获取 ]
欢迎扫码来撩！