1、回顾之前的情况，跟大家聊了一会儿。如果面试的时候遇到消息中间件的话题，面试官可能会上来。问了两个问题：为什么在你们的系统架构中引入消息中间件？在系统架构中引入消息中间件有什么缺点？问完这两个问题，风格不同的面试官可能会问出不同的问题。对于那些工作经验比较长的学长，可能会开始深入研究应聘者所在公司使用的消息中间件的技术细节。比如让你说说RocketMQ的架构原理和核心源码？但是另一种面试风格会从你的项目和业务开始，比如下面这样：消息中间件在你的生产项目中落地到哪个业务场景？这个业务场景中的技术挑战是什么？为什么这个业务场景一定要用到消息中间件技术呢？使用消息中间件时如何使用？2.业务场景介绍我们会登陆到具体业务系统的某个场景，看看消息中间件是如何使用的，然后它的作用是什么。业务场景，我们以大家比较熟悉的电商业务为例。为了便于理解，我们对其进行了一定程度的抽象和简化。让我们考虑下订单的业务流程。比如下单，这时候需要做几件事：更新订单状态为“待发货”（耗时20ms），扣除商品库存（耗时100ms），添加会员积分（耗时80ms）带优惠券（耗时50ms）仓库调度发货（耗时几十秒）。说明：为便于理解，对以上链接进行了简化。在一个真正复杂的电子商务系统中，整体的环节和业务流程会比这复杂很多倍，耗时也绝对不是上面这么简单。老规矩！我们通过一张手绘图来看看整个业务流程：如上图所示，下单业务流程中：更新订单状态（20ms）+扣除商品库存（100ms）+增加会员积分（80毫秒）+优惠券（50毫秒）=250毫秒。也就是说光是这4个进程，就需要200多毫秒。200多毫秒的耗时对于下单的用户体验来说是非常快的。几乎是瞬间完成，没有太多的停顿，也就是说，您可以看到您的订单已成功下单。但是，如果我们添加调度仓库发货呢？该链路需要读取大量数据，使用多仓库/多槽调度算法，并与网络中的C/S存储系统进行通信，因此我们假设该链路可能需要数十秒。一旦在订单流程中加入了调度入库和发货的环节，可能会导致用户在页面卡顿后等待数十秒才能看到下单成功的提示。这个用户体验很差。也就是说，订单服务调度发货到仓库，只是发送一条消息给MQ，然后在仓库服务消费消息后慢慢执行调度算法，然后将产品发货任务分配到相应的仓库。这样一来，下单流程中就可以省去需要几十秒的入库、调度、发货环节。这确保了订单处理仅需200多毫秒。至于需要几十秒的入库、调度、发货环节，我们可以采用异步的方式慢慢执行，不影响用户下单的体验。对于上面的过程，我们也有一张图，大家可以直观的感受一下：3.初始落地好！接下来假设大家在实际生产中没有使用过消息中间件。让我们从0开始，看看如何实现？已经在生产中使用过消息中间件的朋友，不妨看看，温故知新，温故知新没错！我们以RabbitMQ为例。如果你使用的消息中间件是RabbitMQ，那么我们应该如何安装部署这个消息中间件呢？这很简单。RabbitMQ的官方文档提供了非常详细的安装部署步骤。您可以在笔记本电脑上本地安装它，也可以将其部署在公司的服务器上。现在假设你已经参考了官方文档并完成了安装，那么如何在代码层面引入RabbitMQ，实现系统中的消息收发呢？下面通过一些HelloWorld级别的代码和一些简单的示例图来演示RabbitMQ是如何发送和接收消息的。对于很多在实际生产中使用过MQ的同学来说，这些代码对于在实际生产中使用过MQ的同学来说可能显得过于简单了。不过考虑到很多初学者可能连MQ都没用过，甚至不久前听说过消息中间件，我觉得这些demo代码和手工图还是很有必要的。好的！看完代码，这时候我们可以通过一张图来想象两个服务之间的通信。可以启动多个订单服务，不同的订单服务可以向一个RabbitMQ队列推送消息。您也可以启动多个仓储服务。多个仓储服务会使用循环轮询算法，每个服务实例都可以消费RabbitMQ队列中的部分消息。在上图中，订单服务在MQ术语中称为“生产者”，英文为“Producer”，意思是这个服务专门负责生产消息并投递给MQ。仓储服务在MQ术语中称为“消费者”，英文为“Consumer”，意思就是这个服务专门负责消费来自MQ的消息，然后进行处理。这时候这套异步通信架构就可以运行了。好了，到此为止，虽然这段代码还有很多问题，但是已经无所谓了。总的来说，我们已经给一些不熟悉MQ技术的同学，从一个更加生动易懂的简化电商业务场景出发，通过HelloWorld级别的示例代码和手绘图，将MQ技术融入其中手术。更进一步，你可以参考本文的案例思考一下：你负责的项目中有没有类似的可以使用MQ的业务场景？然后想办法在自己的项目中使用MQ技术做异步，提高核心进程的性能。这样，在以后的跳槽面试中，你就能游刃有余，有自己的一套话要说。
