• JMS消息传输机制


    JMS消息传送模型:

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

    JMS具备两种"消息传送模型": P2PPub/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), 然后适时将消息交付给消费者; 这一种有效的担保策略("保存并转发"), 有效的确保了消息的安全性.

  • 相关阅读:
    指定时间 执行且执行1次
    414 URI Too Long 413 Entity Too Large
    golang 高效去重
    try_files $uri $uri/ /index.html;
    a reducer to decide how every action transforms the entire application's state
    慢sql治理经典案例分享
    去中心化的 React Native 架构探索 https://mp.weixin.qq.com/s/c6D0iuDRhTiJwsBqax7nA
    Open Account导入数据 批量导入数据 批量导入 登录名、登录密码 批量添加或修改物料工厂(没有则新增,存在则修改)
    接口响应时间
    重新认识访问者模式:从实践到本质 https://mp.weixin.qq.com/s/670CliuEvIpcI9i8lzwg
  • 原文地址:https://www.cnblogs.com/chy2055/p/5178104.html
Copyright © 2020-2023  润新知