【中间件】JMS

背景：项目升级ActiveMQ启用Cluster模式后，在压力场景下发生消息被重复发送的情况；而刚好系统的消息接收服务没有过滤重复消息的机制，造成系统发出多次重复PUT消息的请求；而远程外接系统针对重复的PUT消息请求会返回409，又刚好触发系统针对409返回的retry机制导致PUT消息再次被多次重发并循环接收409。如此嵌套重发，造成系统资源被耗尽从而服务性能急剧下降。

 

解决：系统改进

1. 加强消息接收服务端，针对redeliveryCounter>=1（即isRedelivered()=true）的message增加过滤重复消息的机制。

2. 加强外接系统返回响应的处理，针对409的返回值，取消触发重发。

 

参考：

https://www.cnblogs.com/csniper/tag/%E4%B8%AD%E9%97%B4%E4%BB%B6/

https://blog.csdn.net/varyall/article/details/49907995

 

SUN及其伙伴公司提出的旨在统一各种消息中间件系统接口的规范(JMS)。

面向消息的中间件（MOM），提供了以松散耦合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送，即应用程序彼此不直接通信，而是与作为中介的MOM通信。MOM提供了有保证的消息发送（至少是在尽可能地做到这一点），应用程序开发人员无需了解远程过程调用（PRC）和网络/通信协议的细节。

 Java Message Service(JMS, Java消息服务)是SUN及其伙伴公司提出的旨在统一各种消息中间件系统接口的规范。它定义了一套通用的接口和相关语义，提供了诸如持久、验证和事务的消息服务，它最主要的目的是允许Java应用程序访问现有的消息中间件。JMS规范没有指定在消息节点间所使用的通讯底层协议，来保证应用开发人员不用与其细节打交道，一个特定的JMS实现可能提供基于TCP/IP、HTTP、UDP或者其它的协议。

目前许多厂商采用并实现了JMS API，现在，JMS产品能够为企业提供一套完整的消息传递功能。

 

选择ActiveMQ为例，按照以下简图：

  ConnectionFactory---->Connection--->Session--->Message
  Destination + Session------------------------------------>Producer
  Destination + Session------------------------------------>MessageConsumer

首先需要得到ConnectionFactoy和Destination，这里创建一个一对一的Queue作为Destination。
  ConnectionFactory factory = new ActiveMQConnectionFactory("vm://localhost");
  Queue queue = new ActiveMQQueue("testQueue");

然后又ConnectionFactory创建一个Connection, 再启动这个Connection:
  Connection connection = factory.createConnection();
  connection.start();

接下来需要由Connection创建一个Session:
  Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE)
    现在暂且不用管参数的含义, 以后会详细讲到.

下面就可以创建Message了,这里创建一个TextMessage。
  Message message = session.createTextMessage("Hello JMS!");

要想把刚才创建的消息发送出去，需要由Session和Destination创建一个消息生产者：
  MessageProducer producer = session.createProducer(queue);

下面就可以发送刚才创建的消息了：
  producer.send(message);

消息发送完成之后，我们需要创建一个消息消费者来接收这个消息：
  MessageConsumer comsumer = session.createConsumer(queue);
  Message recvMessage = comsumer.receive();

消息消费者接收到这个消息之后，就可以得到它的内容：
  System.out.println(((TextMessage)recvMessage).getText());

至此，一个简单的JMS例子就完成了。

 

    一个消息对象分为三部分：消息头(Headers)，属性（Properties）和消息体（Payload）。对于StreamMessage和MapMessage，消息本身就有特定的结构，而对于TextMessage，ObjectMessage和BytesMessage是无结构的。一个消息可以包含一些重要的数据或者仅仅是一个事件的通知。

    消息的Headers部分通常包含一些消息的描述信息，它们都是标准的描述信息。包含下面一些值：

　　JMSDestination 
       消息的目的地，Topic或者是Queue。

　　JMSDeliveryMode 
        消息的发送模式：persistent或nonpersistent。前者表示消息在被消费之前，如果JMS提供者DOWN了，重新启动后消息仍然存在。后者在这种情况下表示消息会被丢失。可以通过下面的方式设置：
       Producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

       JMSTimestamp 
       当调用send()方法的时候，JMSTimestamp会被自动设置为当前事件。可以通过下面方式得到这个值：
       long timestamp = message.getJMSTimestamp();

　　JMSExpiration 
       表示一个消息的有效期。只有在这个有效期内，消息消费者才可以消费这个消息。默认值为0，表示消息永不过期。可以通过下面的方式设置：
       producer.setTimeToLive(3600000); //有效期1小时 （1000毫秒 * 60秒 * 60分）

　　JMSPriority 
       消息的优先级。0-4为正常的优先级，5-9为高优先级。可以通过下面方式设置：
       producer.setPriority(9);

　　JMSMessageID 
       一个字符串用来唯一标示一个消息。

　　JMSReplyTo 
       有时消息生产者希望消费者回复一个消息，JMSReplyTo为一个Destination，表示需要回复的目的地。当然消费者可以不理会它。

　　JMSCorrelationID 
       通常用来关联多个Message。例如需要回复一个消息，可以把JMSCorrelationID设置为所收到的消息的JMSMessageID。

　　JMSType 
       表示消息体的结构，和JMS提供者有关。

　　JMSRedelivered 
       如果这个值为true，表示消息是被重新发送了。因为有时消费者没有确认他已经收到消息或者JMS提供者不确定消费者是否已经收到。如果客户端曾经收到过消息,但是没有签收(acknowledged)，又或是如果消息被重新传送,那么JMSRedelivered=true；反之为false。

    除了Header，消息发送者可以添加一些属性(Properties)。这些属性可以是应用自定义的属性，JMS定义的属性和JMS提供者定义的属性。我们通常只适用自定义的属性。

 

 

消息的重发机制

 

ActiveMQ官方文档：

http://activemq.apache.org/message-redelivery-and-dlq-handling

 

http://activemq.apache.org/redelivery-policy.html

消息在下面几种情况下会被重发：

1. 使用一个事务session，并且调用了rollback()方法；
2. 一个事务session，关闭之前调用了commit；
3. 在session中使用CLIENT_ACKNOWLEDGE签收模式，并且调用了Session.recover()方法；
4. 客户端连接超时（超过配置的time-out时间）。

 

Redelivery Policy

Available Properties

Property	Default Value	Description
backOffMultiplier	5	The back-off multiplier.
collisionAvoidanceFactor	0.15	The percentage of range of collision avoidance if enabled.
initialRedeliveryDelay	1000L	The initial redelivery delay in milliseconds.
maximumRedeliveries	6	Sets the maximum number of times a message will be redelivered before it is considered a poisoned pill and returned to the broker so it can go to a Dead Letter Queue. Set to -1 for unlimited redeliveries.
maximumRedeliveryDelay	-1	Sets the maximum delivery delay that will be applied if the useExponentialBackOff option is set. (use value -1 to define that no maximum be applied) (v5.5).
redeliveryDelay	1000L	The delivery delay if initialRedeliveryDelay=0 (v5.4).
useCollisionAvoidance	false	Should the redelivery policy use collision avoidance.
useExponentialBackOff	false	Should exponential back-off be used, i.e., to exponentially increase the timeout.

 

RedeliveryPolicy per Destination