面试精讲之面试考点及大厂真题分布式专栏13项目中为什么要使用消息队列

13项目中为什么要使用消息队列

学习从来无捷径&＃xff0c;循序渐进登高峰。

—— 高永祚

引言

上个章节把Redis夺命连环问掰扯完&＃xff0c;面试还没有结束&＃xff0c;消息队列同样是面试中必问的&＃xff0c;分布式构建三把斧&＃xff1a;缓存&＃43;异步&＃43;数据分组&＃xff0c;从这节开始进入异步解决方案-消息队列

生活中的队列&＃xff1a;超市买菜排队付款&＃xff0c;出去玩排队上飞机。

&＃xff08;图片来源&＃xff1a;https://medium.com/&＃xff09;

计算机系统中的队列&＃xff1a;

凡是可以“排队”去做的事情&＃xff0c;都可以使用消息队列。网上买东西同样也需要“排队付款”&＃xff0c;但是有人说&＃xff0c;我点确认付款后马上就显示成功了&＃xff0c;没感觉到排队呀&＃xff1f;其实在后台系统中是排了&＃xff0c;只不过排队的时间对于人来说有点短&＃xff0c;可能1-2秒就结束了&＃xff0c;但是对于计算机来说&＃xff0c;这1-2秒的时间很长了。大型分布式系统建设中&＃xff0c;消息队列主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。消息发布者只管把消息发布到 MQ 中而不用管谁来取&＃xff0c;消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。

Web应用程序毫无疑问有大量的代码执行HTTP请求/响应周期的一部分。这适用于更快的任务耗费数百毫秒内或更少。然而&＃xff0c;有些处理&＃xff0c;还需要耗时更多甚至最终会是一两秒钟缓慢的同步执行&＃xff0c;在如此长时间的调用流转中&＃xff0c;肯定有一些调用是可以不同步的&＃xff0c;如下单送积分&＃xff0c;用户下单是最主要的&＃xff0c;送积分的操作可以异步去做&＃xff0c;订单支付成功给用户的短信通知&＃xff0c;返回支付订单进入下一环节更重好&＃xff0c;短信通知可以异步去发送&＃xff0c;为了应对诸如此类的异步操作&＃xff0c;消息队列这门技术应运而生。

1.面试官&＃xff1a;你在项目中使用过消息队列吗&＃xff1f;公司使用什么消息框架。

我&＃xff1a;

我了解的常用消息队列中间件框架

1. ActiveMQ&＃xff1a;由 Apache 出品的一款开源消息中间件。
2. RabbitMQ&＃xff1a;Rabbit科技有限公司开发&＃xff0c;使用Erlang语言开发的开源消息队列系统&＃xff0c;基于AMQP协议来实现。
3. RocketMQ&＃xff1a;阿里巴巴自主开发&＃xff0c;是淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件&＃xff0c;使用MySQL作为消息存储媒介&＃xff0c;可完全水平扩容。
4. Kafka&＃xff1a;最初是由领英开发&＃xff0c;并随后于2011年初开源&＃xff0c;并于2012年10月23日由Apache Incubator孵化出站。

这其中Kafka天生就是分布式设计队列的消息理论上可以分摊到无数服务节点上。同等硬件环境下 Kafka 的性能大大超过传统的 ActiveMQ、RabbitMQ等MQ实现&＃xff0c;这是 Kafka 炙手可热的重要原因&＃xff0c;我们使用的就是Kafka搭建的集群。

Tip&＃xff1a;这只是一个开始&＃xff0c;面试官可能顺着你的话题开始聊Kafka了&＃xff0c;Kafka的特性我在后面单独讲一节&＃xff0c;继续展开讲消息队列基础知识。

2.面试官&＃xff1a;哪些业务场景使用了消息队列&＃xff1f;

问题分析&＃xff1a;
在我刚刚工作接触编程的时候&＃xff0c;做的项目都是单机部署&＃xff0c;一套框架走天下&＃xff0c;根本没有机会使用到消息中间件&＃xff0c;真正参与大型互联网公司的分布式系统后豁然开朗&＃xff0c;原来系统之间通讯是这么轻松愉快。所以如果要拿到大厂offer&＃xff0c;至少要了解一个消息框架。

我&＃xff1a;

“一百字的定义&＃xff0c;不如一句话的实例”

我在公司的核心部分负责的是订单核心系统&＃xff08;具体什么订单系统自行yy一个&＃xff09;。

这是一个完整的外卖订单流程。

从普通用户的角度来看&＃xff0c;一个外卖订单从下单后&＃xff0c;会经历支付、商家接单、配送、用户收货、售后及订单完成多个阶段。

以技术的视角来分解的话&＃xff0c;每个阶段依赖于多个子服务来共同完成&＃xff0c;比如下单会依赖于购物车、订单预览、确认订单服务&＃xff0c;这些子服务又会依赖于底层基础系统来完成其功能&＃xff0c;总之就是一个订单从提单到完成&＃xff0c;要经历一个非常庞杂的流程。

一个服务所需要处理的工作越少&＃xff0c;其性能自然越高。可以通过将部分操作异步化来减少需要同步进行的操作&＃xff0c;进而提升服务的性能。异步化有两种方案。

1. 使用消息队列&＃xff1a;异步操作通过接收消息完成。
2. 使用多线程&＃xff1a;将异步操作放在单独线程中处理&＃xff0c;避免阻塞服务线程。

比如&＃xff0c;日志收集&＃xff0c;采集日志是系统中经常被需要的功能&＃xff0c;业务系统&＃xff08;如订单系统&＃xff09;流量高&＃xff0c;数量极大&＃xff0c;响应时间要求高&＃xff0c;如果想收集订单日志&＃xff0c;收集日志的动作必然不可以影响订单主流程&＃xff0c;采集日志过程就可以使用消息队列模型设计。

再比如&＃xff0c;收银系统&＃xff0c;确认收款成功&＃xff0c;通过MQ通知给物流系统发货&＃xff0c;这些独立系统之间的通讯都需要使用MQ。

再比如&＃xff0c;消费积分&＃xff0c;用户每消费一笔给用户增加一定积分&＃xff0c;京东豆&＃xff0c;信用卡积分&＃xff0c;在一个正规大厂的架构设计中&＃xff0c;可以100%的确定订单系统和积分/奖励系统是耦合在一起的&＃xff0c;那怎么通知积分系统给用户加积分&＃xff1f;这个时候MQ就登场了。

面试官打断了我…

3.面试官&＃xff1a;那为什么不能使用线程池开启多线程呢&＃xff0c;可同样达到异步的效果&＃xff1f;

问题分析&＃xff1a; 千万不能被面试官所迷惑&＃xff0c;他是想要你给出使用消息队列有什么好处。

我&＃xff1a;

这个就要从使用消息队列有什么好处说起了&＃xff0c;我总结了以下几点&＃xff1a;

使用消息队列有什么好处&＃xff1a;

1. 异步处理模式

   比如上面说的日志收集功能&＃xff0c;订单系统是消息发送者&＃xff0c;一行代码发送一条日志消息而无须如何等待。消息发送者将消息发送到一条虚拟的通道&＃xff08;主题 或 队列&＃xff09;上&＃xff0c;日志存储服务作为消息接收者监听该通道&＃xff0c;这样做的好处就是收集日志不会阻碍主流程&＃xff0c;日志积压在消息队列里&＃xff0c;日志服务可以慢慢消化&＃xff0c;也无需很高的性能。

   至于为什么不使用多线程来做&＃xff0c;这就是我要说的第2点。

2. 应用系统解耦

   订单服务和日志存储服务显然是两个服务&＃xff0c;微服务时代&＃xff0c;根据单一职责原则&＃xff0c;订单系统只负责订单相关的工作&＃xff0c;日志收集服务只负责收集日志&＃xff0c;如果把这两件事通过线程池揉在一起&＃xff0c;系统见界限就不明显了&＃xff0c;做不到完全解耦。

3. 流量削峰

   当在线api接口在应对高峰流量时&＃xff0c;比如“秒杀”互动流量激增时&＃xff0c;如果日志服务接口处理能力有限&＃xff0c;可以先将日志消息积压在队列里&＃xff0c;后台慢慢处理&＃xff0c;防止日志服务被打挂。

4. 发布/订阅(Producer–consumer)

   一条消息&＃xff0c;可以广播给任意个收听方&＃xff0c;Producer只负责发送消息 Message&＃xff0c;Consumer可随意订阅 Message。就像广播一样&＃xff0c;是系统之间跨机房跨机器通讯的主要手段。

   场景&＃xff1a;电商系统中&＃xff0c;订单服务和支付服务往往是分开部署在不同机房&＃xff0c;订单系统确认订单&＃xff0c;给用户跳转到支付页面&＃xff0c;支付成功后&＃xff0c;支付系统广播一条 Message&＃xff0c;用户xxx已经确认付款&＃xff0c;订单订阅了此消息&＃xff0c;将要订单状态改成已支付&＃xff0c;物流系统收到支付成功消息开始发货&＃xff0c;整个流程&＃xff0c;系统之间可以通过MQ通讯。
   

面试官欣慰地笑了&＃xff0c;似乎对我对回答很满意&＃xff0c;我似乎也猜到他接下来要问什么了&＃xff0c;关于“使用消息队列有什么缺点”&＃xff0c;不如我一次痛快讲完。

我&＃xff1a;

凡事都有两面性&＃xff0c;不能考虑到消息队列的优点&＃xff0c;分布式环境下&＃xff0c;消息中间件的介入后会为系统提高复杂度&＃xff0c;对应就会需要解决方案&＃xff0c;使用消息中间件会带来什么问题呢&＃xff1f;

使用消息队列有什么缺点&＃xff1a;

1. 消息丢失问题&＃xff1a; 任何系统不能保证万无一失&＃xff0c;比如 Producer 发出了10000条消息&＃xff0c;Consumer 只收到了 9999 个消息&＃xff0c;万有1失&＃xff0c;Consumer 能否接受丢一条&＃xff1f;如果是订单成功短信可以接受丢一条&＃xff0c;就是有一个顾客没有通知到已经发货&＃xff0c;但货还是发出去了&＃xff0c;如果是支付系统&＃xff0c;用户已经付款却因为消息丢失没有通知到订单或物流系统&＃xff0c;那恐怕顾客要找你麻烦了。
2. 消息重复问题&＃xff1a;如 Producer 发出了10000条消息&＃xff0c;Consumer 只收到了 10001 条消息&＃xff0c;有一条是重复的&＃xff0c;业务能否接受一条重复的消息&＃xff0c;这个是作为系统设计者要考虑的问题。
3. 消息的顺序问题&＃xff1a;如 Producer 发送顺序是123&＃xff0c;Consumer 收到的消息是132&＃xff0c;要考虑消费端是否对顺序敏感。
4. 一致性问题&＃xff1a; 如消息丢失问题真的发生且无法找回&＃xff0c;会造成两个系统的数据最终不一致&＃xff0c;如果消息延迟&＃xff0c;会造成短暂不一致。

面试官&＃xff1a;小伙子你考虑地非常全面&＃xff0c;关于消息队列的基础就问到这。&＃xff08;面试官彻底被我折服&＃xff09;。

Tip&＃xff1a;

针对上面的问题都是消息中间件系统带来的常见困扰&＃xff0c;是否需要解决完全依赖业务场景&＃xff0c;如果问题对系统产生影响低可以接受&＃xff0c;可以忽略&＃xff0c;如何解决&＃xff0c;每种消息中间件系统设计方案也有所不同&＃xff0c;还需要考虑从业务上解决&＃xff0c;如消息重复问题&＃xff0c;如果 Consumer 不能接受重复消息&＃xff0c;那 Consumer 的接口可以设计成“幂等”&＃xff0c;这样就不怕重复消息给系统造成影响。

总结

本文主要针对消息队列的概念和使用做了讲解&＃xff0c;消息队列同缓存一样&＃xff0c;几乎是互联网系统建设中不可缺少的&＃xff0c;面试也会被考察&＃xff0c;通常会从以下几个方面进行考察&＃xff1a;

1. 你熟悉哪些消息中间件&＃xff0c;各自有什么优缺点。
2. 为什么使用消息中间件&＃xff1f;
3. 消息队列使用场景。
4. 使用消息中间件有什么缺点&＃xff0c;如何解决。