AMQ学习笔记

概述

---

本文介绍JMS中可能发生消息故障的3个隐患阶段，以及确保消息安全的3种保障机制。

故障分析

---

在介绍可靠传送的确保机制之前，先分析消息在传送的过程中可能在哪个阶段出现问题。

1.两个跃点

跃点的含义在于消息的持有者发生变化，如发送使消息由Producer持有变成JMS Provider持有。在消息传送的过程中，共有2个跃点：

1. 发送跃点
   Producer将消息发送到JMS Provider的目的地
2. 接收跃点
   Consumer从JMS Provider的目的地获取消息

2.三个隐患阶段

在消息传送过程中，可能在三个不同的阶段出现问题：

1. 发送阶段
   Producer发送消息到目的地，可能会失败。
2. 消息缓存阶段
   JMS Provider异常导致目的地中缓存的数据丢失。
3. 接收阶段
   Consumer从目的地接收消息，可能会失败。

可靠传送保障机制

---

为了解决在隐患阶段可能出现的问题，JMS体系定义了几个保障机制：确认、事务、持久化。

1.Acknowledge - 确认

确认是客户端（Producer或Consumer）和JMS Provider之间，为了确保Message的可靠传送而发送消息进行确认的机制。
这个机制可以用于解决发送阶段、接收阶段的安全隐患。

1.1.对于Producer

确认的机制是：生成方调用的send()方法会被阻塞，直到JMS Provider收到了Message、存储到目的地，并发送确认给生成方，阻塞才被解除。

所以，确认机制对于生成方来说是透明的。

1.2.对于Consumer

确认的机制是：消费者从目的地接收Message之后，发送接收确认给JMS Provider，JMS Provider收到确认后，将从目的地中删除该消息，发送处理确认给消费者。

对于消费者而言，有几种确认机制：

• AUTO_ACKNOWLEDGE
  自动确认：会话对收到的每条Message，自动发送接收确认；然后会话线程阻塞，直到收到了JMS Provider发来的处理确认。
  接收确认的发送时机：同步接收中，调用receive()方法成功返回；异步接收中，MessageListener的onMessage(Message)方法被调用，并成功返回。
• CLIENT_ACKNOWLEDGE
  客户端确认：客户端调用Message#acknowledge()发送接收确认^[1]；然后会话线程阻塞，直到收到了JMS Provider发来的处理确认。
  接收确认的发送时机：显示调用Message#acknowledge()方法。
  注：
  [1] 每次确认不是只对当前的Message进行确认，而是对自上次确认以来的所有Message进行确认.
• DUPS_OK_ACKNOWLEDGE
  消息可重复确认：这个机制行为上表现的和AUTO_ACKNOWLEDGE一样，具有延迟确认的特点。这个机制可能会导致收到重复的消息。
  接收确认的发送时机：测试中，PTP Mode每一条消息都会即时确认；Pub/Sub Mode在接收的消息数，每超过prefetch size阀值^[1]一半的时候确认一次。
  注：
  [1] 在brokerURL中可以指定参数jms.prefetchPolicy.topicPrefetch作为prefetch size阀值。你可能会猜测：应该也有参数jms.prefetchPolicy.queuePrefetch，可以让DUPS_OK_ACKNOWLEDGE在PTP Mode中也批量确认。但是实验的结果是每一条消息都会即时确认，就好像DUPS_OK_ACKNOWLEDGE只是针对Pub/Sub设定的。

1.3.确认机制的设置

javax.jms.Session针对三种确认机制，分别定义了整型常量：

• AUTO_ACKNOWLEDGE - 自动确认
• CLIENT_ACKNOWLEDGE - 客户端确认
• DUPS_OK_ACKNOWLEDGE - 可重复确认

 

javax.jms.Connection提供了设置的方法：

• createSession(boolean transacted, int acknowledgeMode):Session
  transacted - 设置事务，后面才会谈到事务，这里设置false就好了
  acknowledgeMode - 设置确认机制

 

确认机制的设置是对于有接收需要的Session来讲的，如果客户端是纯粹的Producer，确认机制的设置应该是被忽略的。鉴于JMS API只提供了上面一个方法来获取Session实例，建议在Producer-Client端获取Session时，使用Connection#createSession(false, Session.AUTO_ACKNOWLEDGE)。对于纯粹的消费者，或者同时作为生产者和消费者，要针对消费的需要来考虑选择哪一个确认机制。

1.4.确认机制的获取

javax.jms.Session提供获取的方法：

• getAcknowledgeMode():int
  返回结果有4种，除了上述的3种确认机制之外，还有一个Session.SESSION_TRANSACTED表示Session启用了事务。

1.5.测试

关于确认机制的测试，参考确认机制的测试。

2.Transaction - 事务

事务用于将多个操作组成一个原子操作，要么全部成功，要么全部失败。与事务相关的两个指令：提交、回滚。当确认所有的操作都是正确的时候，执行提交，这些操作就会生效；当其中有一个操作失败的时候，执行回滚，所有已执行的操作就会撤销。

事务的原理：类比于数据库中的事务，原理相同。事务都是用于对于多个修改性质的操作进行绑定，以这些个修改操作要么全部成功，要么全部失败的保障，来确保数据的一致性。数据库中的事务是对修改数据的行为进行绑定，JMS中的事务是对修改目的地中消息的行为（发送消息、接收消息）进行绑定。

 

如果你对JDBC中的事务有所了解，对比其和JMS中的事务，兴许能帮助你记忆JMS中的事务：

对比内容事务	JDBC事务	JMS事务
范围	java.sql.Connection实例的生命周期之内	javax.jms.Session实例的生命周期之内
设置和获取	java.sql.Connection: setAutoCommit(false) 设置事务 getAutoCommit():boolean 获取事务	javax.jms.Connection: createSession(true, *) 设置事务。 第二个参数可以设置确认模式，可以是任意值：启用了事务就会忽略确认模式。 不过建议使用Session.SESSION_TRANSACTED javax.jms.Session: getTransacted():boolean 获取事务
操作	java.sql.Connection: commit():void 提交 rollback():void 回滚	javax.jms.Session: commit():void 提交 rollback():void 回滚

 

事务的设置和确认机制的设置使用同一个方法，那么有必要把确认机制和事务进行对比：

对比内容机制	确认机制	事务机制
本质	确保消费者能够获取到消息，在收到消费者的确认之后，才会将消息从目的地移除。	将多个操作绑在一起，成为原子操作，从而有相同的操作结果（成功或失败）。
客户端编程	在Producer端是透明的，只能在Consumer端进行控制。	可以在Producer和Consumer端实施控制。
功能性	确认消息已收到。	事务的commit，提供类似于批量确认的功能。 不要单纯为了批量确认而使用事务，要从业务的需要上考虑使用事务。

因为事务机制提供了确认的功能，所以确认机制和事务机制是互斥的。Connection#createSession(boolean transacted, int acknowledgeMode)方法用于设置事务或确认：

• 如果第一个参数为true，表示启用事务，第二个参数就会被忽略（建议传入Session.SESSION_TRANSACTED）
• 如果第一个参数为false，表示不启用事务，第二个参数用于设置确认模式，就有效了。

2.1.使用模型

 1 try {
 2     // ...
 3     javax.jms.Connection connection = ...;
 4     javax.jms.Session session = connection.createSession(true, Session.SESSION_TRANSACTED);
 5     
 6     // send or receive operates
 7     
 8     session.commit(); // commit at lase
 9 } catch(JMSException e) {
10     session.rollback(); // rollback when exception happens
11 } finally {
12     // close resources
13 }

2.2.测试

关于事务的测试，参考事务的测试。

3.持久化模式

确认模式和事务模式足以^[1]处理发送阶段、接收阶段的安全隐患，持久化的机制则用来处理消息在目的地阶段的安全隐患。

如果Producer选择不使用持久化，则消息缓存在内存中，虽然可以获得高吞吐率，但是一旦JMS Provider宕掉，就会导致消息的丢失。非持久化具有高吞吐量和低可靠性的特点。

如果Producer选择持久化，则JMS Provider会将消息存到物理媒介上（文件、数据库），Consumer获取消息，也是从物理媒介读取，吞吐量受到影响，但是即使JMS Provider宕掉，消息也不会丢失。持久化具有低吞吐量和高可靠性的特点。

针对持久化，JMS Provider可以提供多种持久化方案，比如持久化到本地文件、不同的数据库等，不过这些不是Producer需要关心的，Producer只需要告诉JMS Provider要不要持久化消息就好了。

持久化方案的选择，在%ActiveMQ_HOME%confactivemq.xml文件，<persistenceAdapter />元素下配置。可以参考ActiveMQ持久化，这里不介绍这块内容。

 

补充：

[1] 实际上，在发送阶段需要我们自己提供容错方案 - 比如对发送失败的消息，缓存到本地文件等。

3.1.持久化设置

javax.jms.MessageProducer:

• setDeliveryMode(int):void
  - 设置此producer实例的默认递送模式
• send(Message message):void
  - 以默认的deliveryMode发送消息
• send(Message message, int deliveryMode, int priority, long timeToLive):void
  - 以指定的deliveryMode发送消息

 

javax.jms.DeliveryMode

• static int NON_PERSISTENT
  非持久化模式
• static int PERSISTENT
  持久化模式

 

设置递送模式的代码：

producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT); // 非持久化
producer.setDelicertMode(DeliveryMode.PERSISTENT); // 持久化

3.2.测试

参考持久化的测试。

参考

---

1. 第 2 章 客户端编程模型
   本文的骨架是参考这篇文章整理的
2. ActiveMQ讯息传送机制以及ACK机制
   这篇文章对ACK的机制讲的比较细，我尝试了optimizeACK + prefetch + AUTO_ACKNOWLEDGE的预取机制，以及DUPS_OK_ACKNOWLEDGE在Pub/Sub模式下的延迟确认机制。
3. ActiveMQ持久化
   介绍了几种常见的持久化方案。