【RabbitMQ官网教程系列】二、初识MQ（中）

一、前情回顾

信息流回顾

在上一篇文章中，我们列举了收费站ETC的例子。

简单的梳理一下信息的流转过程：

【摄像头】识别到车牌号信息之后，将信息发送给【收费站ETC程序】；

【收费站ETC程序】将信息进过加工之后，发送给【后台ETC程序】；

【后台ETC程序】会发送一个扣费信息给【银行后台程序】；

【银行后台程序】扣费成功后，返回信息给【后台ETC程序】；

【后台ETC程序】再返回信息给【收费站ETC程序】，【收费站ETC程序】控制栏杆抬起，车辆通过。

完整的信息流图如下所示：

问题回顾

上述信息流的问题，我们之前的文章也提到了。

由于银行后台程序无法保证24小时运行，进而会对这套ETC系统造成影响。在银行后台程序奔溃或者维护期间，整个ETC系统是无法使用的

2. 问题解决——引入MQ

如何解决这个问题呢？引入MQ！

【后台】ETC程序与【MQ】的信息交互

我们在【后台ETC程序】和【银行后台程序】之间，再加入一个MQ组件！如下图所示

这里我们做如下说明：为确保图示简洁，我们本篇文章的图示中，会忽略【车】、【摄像头】、【收费站ETC程序】三个组件

如上图，我们在两个组件之间增加了一个【MQ】组件。那么对于【后台ETC程序】来说，整个信息流就简化成了：

• 接收到车辆出站信心
• 将信息发送给MQ
• MQ将信息存储起来
• MQ接收到后返回【缓存成功】给【后台ETC程序】
• 后台ETC程序返回信息

这里我们不是直接和【银行后台程序】进行信息交互，而是将信息发送给MQ组件。只要MQ组件接收到信息，并将信息存储起来，就返回消息给【后台ETC程序】

到这里我们暂停一下，想想上面的这套机制，是否已经解决了我们的问题呢？

答案是肯定的！【后台ETC程序】只需要确保将消息成功发送给了【MQ】，就返回信息，这中间根本不需要与【银行后台程序】进行交互。

换句话说，即使银行后台程序奔溃，对我们ETC系统根本没有影响！这不就解决了由于【银行后台系统】不可用而造成的ETC系统不可用的问题了么？

看到这里，有的小伙伴可能会问：那MQ组件奔溃了，不照样会造成ETC系统不可用么？

确实如此。所以我们在部署MQ的时候，需要确保它的实时可用。这里我们不展开讲，后续会有专门的文章来讲解如何确保。同时我们要意识到，【MQ】是我们ETC系统开发运维人员，自己部署的一个组件。确保自己的组件实时可用，比确保第三方的【银行后台程序】实时可用要靠谱的多，对吧！

MQ消息缓存

当我们【后台ETC程序】将消息发送给【MQ】之后，MQ会将这个消息存储起来。如果【后台ETC程序】发送了3条消息呢？那【MQ】就会缓存3条消息。在MQ中，同一类型的消息是放在一个队列里的，所以MQ（Message Queue）这个名字便由此而来

我们假设【后台ETC程序】已经发送了3条消息给MQ了，那此时MQ中存储消息的示意图如下

【银行后台程序】扣款

上面的信息流中，我们少了一个很重要的环节：银行扣款！

我们将银行扣款的信息补充到图示中

通过上图，我们可以发现：【MQ】与【银行后台程序】间的信息交互，分为3步：

• MQ发送信息给【银行后台程序】
• 【银行后台程序】完成扣款操作
• 【银行后台程序】返回信息给MQ

3. 总结

从上面的信息流转图我们可以看出，我们将【后台ETC程序】和【后台银行程序】间的信息交互，通过MQ拆分成了两个部分：

• 【后台ETC程序】与【MQ】间的信息交互
• 【MQ】与【银行后台程序】的信息交互
  这两者是彼此独立、互不干扰的！

当【银行后台程序】宕机时，【后台ETC程序】只需要确保消息能不断的发送给MQ；

而当【银行后台程序】宕机重启之后，只需要从MQ中不断的将缓存在其中的消息取出并处理即可。

这样一来，我们就通过MQ，实现了ETC程序的实时可用性。

下一讲中，我们结合本篇实例，来着重说说MQ的三大作用：异步、削峰、解耦