JMS消息传输机制

JMS消息传送模型:

  消息传送机制, 是基于拉取(pull)或者轮询(polling)的方式. 

JMS具备两种"消息传送模型": P2P和Pub/sub.

(1) P2P:点对点消息传送模型, 允许JMS客户端通过队列(queue)这个虚拟通道来同步或异步发送消息; 消息的生产者为Sender, 消费者为receiver.

       receiver主动到队列中请求消息,而不是JMS提供者将消息推送到客户端;

       主要原因是一个队列通道可能有多个receiver,每个receiver可能对消息的处理速率不同(因处理消息而造成的阻塞时间不同),对于JMS提供者而言,它无法意识到哪个receiver处于"空闲"状态,如果JMS提供者主动推送会造成通道的阻塞或者消息在客户端积压等问题;所以基于客户端pull的方式,当receiver空闲时向JMS提供者请求消息,很好的解决了这个问题,而且还能进行良好的"负载均衡".

    Queue中的消息如果被某个recervier成功接收(确认成功)后, 消息就会被移除.

    P2P消息传送模式即支持异步"即发即失",也支持同步的"请求/应答".

(2) Pub/sub:发布/订阅模型中,消息会发布到一个名为主题(Topic)的虚拟通道中,消息的生产者为Publisher,消费者为subscriber,发布到Topic中的消息,可以被多个客户端同时接收.

        pub/sub消息传送模型是基于推送(push),JMS提供者将消息主动推送给及客户端,类似于广播;之所以采取此方式,其实很好理解,既然每个客户端都应该收到消息,那么对于JMS提供者而言,只需要遍历所有的"活跃"的链接,依次将消息发送出去即可,而无需客户端"徒劳"的去轮询.

       在Pub/sub模型内部,有多种不同类型的订阅者;非持久订阅者是临时订阅者,它们只是在主动侦听主题式才能收到消息;持久订阅者将接收到发布的每一条消息,即使它的链接处于"离线".此外还有"动态持久订阅者"和"受托管的持久订阅者".

    JMS提供者都支持"消息"的持久化, 任何发送给JMS提供者的消息, 都会首先被持久存储(对于非持久类型的数据,是基于cache), 然后适时将消息交付给消费者; 这一种有效的担保策略("保存并转发"), 有效的确保了消息的安全性.

时间: 2024-10-12 13:50:29

JMS消息传输机制的相关文章

【Unity】线程安全的消息传输机制,仿照Cocos实现

近期用到了网络通信的方法,虽然unity可以用协程来实现异步操作,不过坑爹的队友不会用,他用的是传统的开线程的方法,这样就会出现线程安全的问题,然后现有的消息通信机制无法满足需求了,就得改了.还好我机智的看过Cocos2dx中消息机制的实现原理,顺手改了一下,下面贴源码:(源码后有解释) using System; using System.Collections; using System.Collections.Generic; using UnityEngine; /** * 消息派发类

医疗行业多层级复杂网络环境下的消息传输(远程会诊)架构与实现

近期接手一个针对医疗系统远程会诊平台的技术改造工作,这项工作中的一些技术问题颇具代表性,我会在此记录这一工作的过程和技术细节,如果条件允许,会在 GitHub 上开源部分业务无关的纯技术实现,敬请关注.(https://github.com/iccb1013). 远程会诊平台的应用场景指的是乡镇或县卫生所,在接诊过程中,对疑难问题上报上级医疗机构,由上级医疗机构进行网络诊断并回复诊疗意见,但是这一过程,并不是简单的点对点的关系.主要特点:1)  包含多级机构:乡镇.县.区.市.省.由任意一级向上

ActiveMQ源码解析(四):聊聊消息的可靠传输机制和事务控制

在消息传递的过程中,某些情况下比如网络闪断.丢包等会导致消息永久性丢失,这时消费者是接收不到消息的,这样就会造成数据不一致的问题.那么我们怎么才能保证消息一定能发送给消费者呢?怎么才能避免数据不一致呢?又比如我们发送多条消息,有时候我们期望都发送成功但实际上其中一部分发送成功,另一部分发送失败了,没达到我们的预期效果,那么我们怎么解决这个问题呢? 前一种问题我们通过消息确认机制来解决,它分为几种模式,需要在创建session时指定是否开启事务和确认模式,像下面这样: <span style=&quo

学习ActiveMQ(六):JMS消息的确认与重发机制

当我们发送消息的时候,会出现发送失败的情况,此时我们需要用到activemq为我们提供了消息重发机制,进行消息的重新发送.那么我们怎么知道消息有没有发送失败呢?activemq还有消息确认机制,消费者在接收到消息的时候可以进行确认.本节将确认机制和重发机制一起在原有的代码中学习. 消息确认机制有四种:定义于在session对象中 AUTO_ACKNOWLEDGE= 1 :自动确认 CLIENT_ACKNOWLEDGE= 2:客户端手动确认 UPS_OK_ACKNOWLEDGE= 3: 自动批量确

JMS消息的可靠性机制

ActiveMQ消息签收机制: 客户端成功接收一条消息的标志是一条消息被签收,成功应答. 消息的签收请求分为两种: 1.带事务的session 如果session带有事务,并且事务成功提交,则消息被自动签收.如果事务回滚,则消息会被再次传送. 2.不带事务的session 不带事务的session的签收方式,取决于session的配置 ActiveMQ支持以下三种模式: Seesion.AUTO_ACKNOWLEDGE:消息自动签收: Session.CLIENT_ACKNOWLEDGE:客户端

activemq的消息确认机制ACK

一.简介 消息消费者有没有接收到消息,需要有一种机制让消息提供者知道,这个机制就是消息确认机制. ACK(Acknowledgement)即确认字符,在数据通信中,接收站发给发送站的一种传输类控制字符.表示发来的数据已确认接收无误. 二.ACK_MODE有几类 我们在开发JMS应用程序的时候,会经常使用到上述ACK_MODE,其中"INDIVIDUAL_ACKNOWLEDGE "只有ActiveMQ支持,当然开发者也可以使用它. ACK_MODE描述了Consumer与broker确认

activeMq-JMS消息可靠性机制-4

消息接收确认 JMS消息只有在被确认之后,才认为已经被成功地消费了. 消息的成功消费通常包含三个阶段:客户接收消息.客户处理消息和消息被确认. //参数1:是否启用事务(false表示不开启事务) 参数2:接收模式(一般设置为自动接收) Session session = connection.createSession(Boolean.FALSE, Session.AUTO_ACKNOWLEDGE); 在事务性会话中,当一个事务被提交的时候(session.commit() ),确认自动发生.

如何优化传输机制来实现实时音视频的超低延迟?

1.前言 要在语音视频 SDK 中实现超低延迟,实时的语音视频传输机制是必不可少的,而 FEC 和 ARQ 的智能结合是实时语音视频传输机制的基石. 在语音社交.视频社交.游戏语音和互动直播等领域,关于在语音视频实时传输中实现低延迟这个议题,已经有不少的文章提出各种方案.绝大部分方案的思路都是"优化",比如说,优化编码.推流.传输和播放等各个环节. 愚以为,要在实时语音视频传输中获得超低延迟,是不能单靠挖空心思去"优化"的,而是要依靠实时的传输机制.就像高铁和火车有

JMS消息服务器——Message消息分析(1)

一.Message结构 Message消息是整个JMS规范最为重要的部分.一个JMS应用程序中的所有数据和事件都是使用消息进行通信的,同时JMS的其余部分也都在为消息传输服务.因此可以说,消息时一个系统的命脉所在. 一个Message对象有3个部分:消息头.消息属性,最后就是消息数据内容,它称为负载或消息体. 二.消息头 每条JMS消息都有一组标准的消息头.每个消息头都由一组取值函数和赋值函数所标识.这些方法名称紧随在术语setJMS**(),getJMS**()方法之后.如下图: JMS消息可