时间戳

首页 > 技术文章 > activeMQ--JMS

activeMQ--JMS

zzhAylm 2021-05-27 21:17 原文

  1. 是什么
    1. javaEE
      •  
    2. JMS : Java Message Service(Java消息服务是JavaEE中的- -个技术)

      • 　　
  2. MQ中间件的其他落地产品
    •  

    •  

  3. JMS的组成结构和特点
    1. JMS  provider：实现JMS接口和规范的消息中间件，也就是我们的MQ服务器
    2. JMS producer：消息的生产者，常见和发送JMS消息的客户端应用
    3. JMS consumer：消息的消费者，接收和处理JMS消息的客户端应用
    4. JMS message：（可以在message.属性设置，也可以咋message.send()方法里面设置属性）
      1. 消息头

        • JMSDestination：消息发送的目的地，主要是指Queue和Topic

        • JMSDeliveryMode：

        • JMSExpiration：

        • JMSPriority：

        • JMSMessagelD：

          • 唯一识别每个消息的标识有MQ产生　　
      2. 消息体
        • 封装具体的消息数据
        • 5中消息体格式
          1. TextMessage：普通的字符串消息，包含一个String 
          2. MapMessage：一个Map类型的消息，key为String类型的，而值为java的基本类型
          3. BytesMessge：二进制数组消息，包含一个byte[]
          4. StreamMessage:Java数据流消息，用标准流操作来顺序的填充和读取
          5. ObjectMessage：对象消息，包含一个可序列化的java对象
        • 发送和接受的消息体类型的必须一致对应　　
      3. 消息属性
        • 如果需要出消息头以外的字段的值，那么可以使用消息属性
        • 识别/去重/重点标注等操作非常有用的方法
        • 是什么

          • 　　　
  4. JMS的可靠性：
    1. PERSISRENT:持久化
      • 参数设置说明（ setDeliveryMode（）：消息的提供者属性设置消息是否进行持久化）：
        1. 非持久:
          • 非持久化：当服务器宕机，消息不存在。 非持久化:当服务器宕机，消息不存在.（先发送消息，发送后还没有消费，此时发生宕机，非持久化的数据会丢失，而持久化的不会丢失）
          • messageProducer. setDeliveryMode (DeliveryMode . NON_ PERSISTENT); 信息制作者。SetDeliveryMode(DeliveryMode)非持久性)；

          • 　　
        2. 持久：
          • 持久化：当服务器宕机，消息依然存在。 持久化:当服务器宕机，消息依然存在.
          • messageProducer . setDel iveryMode(DeliveryMode. PERSISTENT); 信息制作者。SetDel iveryMode(DeliveryMode)(A)持续存在)；
        3. 当不是设置消息提供者的setDel iveryMode(）属性是，默认情况因为我们使用的是队列，默认情况是持久化的，宕机后会保存消息
          •  
      • 持久的Queue：

        • 　　
      • 持久的Topic
        • 生产者改造，改为生产持久化的topic：

        • 消费者创建，改为持久的订阅者

        •  

          订阅者运行一次，相当域订阅了消息，无论订阅者在线还是不在线，消息的生产这都会给订阅者发送消息，在线时直接发送，不在线是，等到上线了直接发送
        • 如是再无订阅者的情况下，发送消息会成为废消息　　
        •  
          　　
    2. 事务
      1. producer提交的事务（两种参数，createsession（false/true））
        • false
          • 只要执行send，就会进入到队列中
          • 关闭事务，那第二个签收参数的设置需要有效

        • true　
          • 先执行send在执行commit，消息才会被提交到队列中
          • 消息需要批量的发送，需要缓冲区处理

          • 参数为true的好处，批处理，同时成功，同时失败，对消息提交时，如果中间出现错误，我们可以使用rollback（）方法进行回滚

          •  

      2. 消息的消费者事务
        • 当提交事务的参数为false时，对于订阅的消息只接受一次

        • 当提交的事务参数为true时

          1. 当不执行commit时，前台多次接受订阅的消息，但是后台始终无法感应到订阅者的消费。造成重复消费

          2. 当提交后，后台才会将消息状态变为已消费

            • ·　　　　　　　
      3. 事物偏生产者/签收偏消费者　　　　
    3. Acknowledge:签收（俗称ack）
      • 非事务情况：
        1. 自动签收（默认）

          1. Session. AUTO_ ACKNOWL EDGE

        2. 手动签收:
          1. Session. CL IENT ACKNOWL EDGE
          2. 客戶端调用acknowledge方法手动签收 ：message.acknowledge();
          3. 当手动签收时，没有签收，会造成重复消费

          4. 使用 message.acknowledge（）函数进行  签收，手动签收的方式必须要进行签收

            • 　　　　
        3. 允许重复消息(允许重复签收): Session. DUPS_ OK_ ACKNOWL EDGE　　　
      • 在事务开启情况：
          • 事务开启，手动签收，未添加签收，添加了提交的情况，（开启事务默认签收）是正确的，不会出现无人签收重复签收的情况
          • 事务开启，手动签收，开启ack签收，未添加commit提交，会出现重复消费，出现错误，是无比签收更加大，可以不添加ack但是不能没有commit提交。

          • 　　　　
      • 签收和事务的关系　

        • 在事务性会话中，当一个事务被成功提交则消息被自动签收。.

        • 如果事务回滚，则消息会被再次传送。

        • 非事务性会话中，消息何时被确认取决于创建会话时的应答模式(acknowledgementmode)

          　　　
  5. JMS的点对点的总结

    • 　　
  6. JMS的发布与订阅总结

    • 假如你的消息允许丢失我们可以使用非持久订阅

    • 你的消息不允许丢失时，我们使用持久订阅

    • 定义持久化订阅者：

推荐阅读