在上一篇文章中,我们列举了收费站ETC的例子。
简单的梳理一下信息的流转过程:
【摄像头】识别到车牌号信息之后,将信息发送给【收费站ETC程序】;
【收费站ETC程序】将信息进过加工之后,发送给【后台ETC程序】;
【后台ETC程序】会发送一个扣费信息给【银行后台程序】;
【银行后台程序】扣费成功后,返回信息给【后台ETC程序】;
【后台ETC程序】再返回信息给【收费站ETC程序】,【收费站ETC程序】控制栏杆抬起,车辆通过。
完整的信息流图如下所示:
问题回顾上述信息流的问题,我们之前的文章也提到了。
由于银行后台程序无法保证24小时运行,进而会对这套ETC系统造成影响。在银行后台程序奔溃或者维护期间,整个ETC系统是无法使用的
2. 问题解决——引入MQ如何解决这个问题呢?引入MQ!
【后台】ETC程序与【MQ】的信息交互我们在【后台ETC程序】和【银行后台程序】之间,再加入一个MQ组件!如下图所示
这里我们做如下说明:为确保图示简洁,我们本篇文章的图示中,会忽略【车】、【摄像头】、【收费站ETC程序】三个组件
如上图,我们在两个组件之间增加了一个【MQ】组件。那么对于【后台ETC程序】来说,整个信息流就简化成了:
接收到车辆出站信心将信息发送给MQMQ将信息存储起来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的三大作用:异步、削峰、解耦
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)