阅读 111

【java开发消息中间件MQ篇】之MQ的消息传递方式

前言: mq的种类很多,知识点也很多,容我娓娓道来,此文章仅代表鄙人的总结和理解,如有错漏,欢迎指正...

发布订阅模式

发布订阅模式有点类似于我们日常生活中订阅报纸。每年到年尾的时候,邮局就会发一本报纸集合让我们来选择订阅哪一个。在这个表里头列了所有出版发行的报纸,那么对于我们每一个订阅者来说,我们可以选择一份或者多份报纸。比如北京日报、潇湘晨报等。那么这些个我们订阅的报纸,就相当于发布订阅模式里的topic。有很多个人订阅报纸,也有人可能和我订阅了相同的报纸。那么,在这里,相当于我们在同一个topic里注册了。对于一份报纸发行方来说,它和所有的订阅者就构成了一个1对多的关系。这种关系如下图所示:


发布订阅模式

点对点模式

点对点模式就相当于打电话,由两端的双方独享这一通信链路


点对点模式

扩展的对点模式

和前面两种方式比较起来,request-response的通信方式很常见,但是不是默认提供的一种模式。在前面的两种模式中都是一方负责发送消息而另外一方负责处理。而我们实际中的很多应用相当于一种一应一答的过程,需要双方都能给对方发送消息。于是请求-应答的这种通信方式也很重要。它也应用的很普遍。
请求-应答方式并不是JMS规范系统默认提供的一种通信方式,而是通过在现有通信方式的基础上稍微运用一点技巧实现的。下图是典型的请求-应答方式的交互过程:


request-response

我在项目中的理解

MQ其实就是一个消息中转站。
在企业级的应用里,会有一个服务器集群来作为这个中转站,这个集群中有主从,有备份,有路由,有网关。此时MQ就是就是一种中间件,在个人的实验中体会不到这种感觉。
企业级的MQ不仅仅实现了简单的消息中转站的功能,还实现了消息生产者和消息消费者的认证功能(即他们能消费和生产哪些具体的topic)。
附一张企业MQ的架构图

MQ的缺点

1、mq的主要问题在于重复生产和重复消费(延迟也是一个很大的缺点,但是这可以换来性能上的提升,监听获取信息肯定比轮询获取信息的效率高)。
2、比如几个业务系统需要消费一个点对点模式的mq消息,其中一个业务系统消费成功了但是并没有向mq服务器成功发送消费成功的确认ack,导致消息在mq服务器中依然存在,从而导致其他业务系统的重复消费。
3、再比如生产者如果没有接收到mq服务器的确认消息,就会重复生产,如果在服务器没有相应的去重措施,就会带来很大的隐患。
4、所以在使用MQ的时候,最重要的问题不是在于怎么去用它,而是怎么在业务系统中解决重复生产和重复消费的问题。具体的得根据系统允许的容错率和业务来进行相应的处理。
5、我主要说一下在服务器端对MQ进行去重的方法,如果是同一topic的信息,可以通过对消息内容进行摘要运算从而达到简单的去重效果。

实现可靠MQ和去重参考方法

1、消息的可靠性设计,目前有2种模式:模式1是采用Notify的方式,先发送半消息,业务操作成功后最后提交完整消息,同时提供业务操作的检查接口,这种模式实现消息的最终一致性;模式2将业务数据和消息数据先都存在业务数据库里面,通过数据库的事务保证一致性,随后将消息转发给MQ。模式1的缺点是业务侵入性高,方案比较复杂,需要重新实现;模式2的缺点是消息数据可能会散落在各个地方,包括业务系统,而且可以集成现有MQ。

2、消息去重设计,也有2种模式:模式1是消费者根据自己的业务实现去重,模式2是在消费者端增加一个数据库表专门记录已经消费过的消息,不需要消费者根据业务去做去重。

参考博客 --》 理解JAVA MQ消息中间件

更多相关【java开发消息中间件MQ篇】系列文章,请查阅我的个人博客哦...


结语:以往都是看别人的博客进行学习技术,其中不乏有精华博客也有吊儿郎当的CV大法文章,所以决定将自己所学所用所整理的知识分享给大家,主要还是想为了后浪们少走些弯路,多些正能量的博客,如有错漏,欢迎指正,仅希望大家能在我的博客中学到知识,解决到问题,那么就足够了。谢谢大家!(转载请注明原文出处)