标签:效率 ima 集成 链路 完整 img image rip 电话
发布订阅模式有点类似于我们日常生活中订阅报纸。每年到年尾的时候,邮局就会发一本报纸集合让我们来选择订阅哪一个。在这个表里头列了所有出版发行的报纸,那么对于我们每一个订阅者来说,我们可以选择一份或者多份报纸。比如北京日报、潇湘晨报等。那么这些个我们订阅的报纸,就相当于发布订阅模式里的topic。有很多个人订阅报纸,也有人可能和我订阅了相同的报纸。那么,在这里,相当于我们在同一个topic里注册了。对于一份报纸发行方来说,它和所有的订阅者就构成了一个1对多的关系。这种关系如下图所示:
点对点模式就相当于打电话,由两端的双方独享这一通信链路
和前面两种方式比较起来,request-response的通信方式很常见,但是不是默认提供的一种模式。在前面的两种模式中都是一方负责发送消息而另外一方负责处理。而我们实际中的很多应用相当于一种一应一答的过程,需要双方都能给对方发送消息。于是请求-应答的这种通信方式也很重要。它也应用的很普遍。
请求-应答方式并不是JMS规范系统默认提供的一种通信方式,而是通过在现有通信方式的基础上稍微运用一点技巧实现的。下图是典型的请求-应答方式的交互过程:
MQ其实就是一个消息中转站。
在企业级的应用里,会有一个服务器集群来作为这个中转站,这个集群中有主从,有备份,有路由,有网关。此时MQ就是就是一种中间件,在个人的实验中体会不到这种感觉。
企业级的MQ不仅仅实现了简单的消息中转站的功能,还实现了消息生产者和消息消费者的认证功能(即他们能消费和生产哪些具体的topic)。
附一张企业MQ的架构图
消息的可靠性设计,目前有2种模式:模式1是采用Notify的方式,先发送半消息,业务操作成功后最后提交完整消息,同时提供业务操作的检查接口,这种模式实现消息的最终一致性;模式2将业务数据和消息数据先都存在业务数据库里面,通过数据库的事务保证一致性,随后将消息转发给MQ。模式1的缺点是业务侵入性高,方案比较复杂,需要重新实现;模式2的缺点是消息数据可能会散落在各个地方,包括业务系统,而且可以集成现有MQ。
消息去重设计,也有2种模式:模式1是消费者根据自己的业务实现去重,模式2是在消费者端增加一个数据库表专门记录已经消费过的消息,不需要消费者根据业务去做去重。
标签:效率 ima 集成 链路 完整 img image rip 电话
原文地址:https://www.cnblogs.com/panchanggui/p/10265703.html