ActiveMQ介绍（一）
本文主要介绍一下ActiveMQ的使用方法，介绍ActiveMQ的基本概念和相关示例。
1.名词定义
Acknowledge：消息确认，表示已经成功接收到消息。
JMS：Java消息服务
JMS Client：JMS客户端，包括生产者（Producer）和消息的消费者（Consumer）
JSM Broker：JMS服务提供者，负责与Client同薪，是消息生产者和消费者之间的中转站
ConnectionFactory：由客户端使用，用来创建一个连接
Connection：连接，包括Transport和Network两种
Transport Connector：主要负责Broker和Client之间的通信，支持TCP/NIO/SSH/STOMP等协议
Network Connector：主要负责Brokers之间的通信
Session：用来发送和接受消息的线程上下文
MessageProducer：由Session对象创建的消息生产者，以下简称Producer
MessageConsumer：由Session对象创建的消息消费者，以下简称Consumer
Produce：Producer发送一个消息
Consume：Consumer接受到一条消息
Destination：一个消息的目的地址或者源地址，这个类是Queue和Topic的超类
Queue：用于端对端（PTP）模式的目的地址
Topic：用于发布订阅（Pub/Sub）模式的目的地址
2.JMS
2.1 简介
消息中间件（message-oriented middleware，MOM）是在应用程序之间或者分布式系统中，以一种异步，松散耦合，可靠的方式进行通信的一类软件。由于消息中间件的引入，使得消息源到目的端的两点通信变成了源端、消息中间件、目的端的三点通信。
JMS（Java message service）是一种面向消息中间件的API，同时也是一种技术规范，便于消息系统中的应用程序进行消息交互。类似于JDBC访问不同厂商的关系数据库一样，JMS提供了与厂商无关的访问消息系统的方法。ActiveMQ就是一种实现了JMS规范的消息中间件产品。
2.2 JMS的基本构件
ConnectionFactory：连接工厂是客户用来创建连接的对象，例如ActiveMQ提供的ActiveMQConnectionFactory，通过这个对象可以创建消息客户端到消息服务提供者之间的连接。
Connection：JMS Connection封装了客户到JMS服务提供者之间的一个虚拟的连接。它代表消息客户端到消息服务器之间的逻辑通道。
Session：JMS Session是生产和消费消息的一个单线程上下文。会话用于创建消息生产者（producer）、消息消费者（consumer）和消息（message）等。会话提供了一个事务性的上下文，在这个上下文中，一组发送和接受被组合到了一个原子操作中。
Destination：目的地是客户用来指定它生产的消息目标和它消费的消息的来源的对象。JMS1.1规范中定义了两种消息传递模型：点对点（PTP）消息传递模型和发布/订阅消息传递模型。这两种模式对应于ActiveMQ的两个消息域：在点对点消息传递域中，目的地被称为队列（queue）；在发布/订阅消息传递域中，目的地被称为主题（Topic），消息传递方式见下图：
如图，ClientA、B是消息生产者，Client C、D、E、F是消息消费者，生产者A、B分别以两种不同的模式向消费者发送消息。
1.ClientA->Client C、D之间的消息传递采用是点对点模式，这种模式对应ActiveMQ和Queue消息域。生产者A发送消息到broker和queue目的地，broker按照一定的规则（可配置）把这条消息分发给注册在这个队列上的某一个消费者。同一条消息只会被一个消费者所消费。按照默认的转发规则，ClientA产生的消息会依次轮转投递给Client C和D。
2.ClientB->ClientE、F之间的消息传递采用的是发布/订阅模式，这种模式对应于ActiveMQ的Topic消息域。生产者B发送消息到broker的topic目的地，broker会把这条消息转发给注册在这个topic上的所有消费者ClientE、F。同一条消息会被所有消费者消费。
点对点消息传递域的特点如下：
·每个消费只能有一个消费者
·消息生产者和消费者之间没有时间上的相关性。无论消费者在生产者发送消息的时候是否处于运行状态，它都可以提取消息
发布/订阅消息传递的特点：
·每个消息可以有多个消费者
·生产者和消费者之间有时间上的相关性。订阅一个主题的消费者只能消费自它订阅之后发布的消息。JMS规范允许客户创建持久订阅，这在一定程度上放松了时间上的相关性要求。持久订阅允许消费者消费它在未处于激活状态是发送时发送的消息。
Client：
JMS Client实现了MessageProducer和MessageConsumer接口。也就是说，客户端分成了两种类型：用于发送消息的消息生产者（Producer）和用于接收消息的消息消费者（Consumer）
Message Producer：
消息生产者是由会话创建的一个对象，用于把消息发送到一个目的地。客户端使用MessageProducer来向Destination发送消息。通过向会话的createProducer()方法传入Queue或Topic来创建MessageProducer。客户端也可以不提供目的地来创建消息生产者。在这种情况下，必须在每次发送操作时提供目的地。这种风格的生产者通常用于使用请求的JMSReplyTo目的地来发送请求的回复。客户端也可以指定一个缺省的转发模式，优先级和消息的生存时间。它也可以为每个消息指定转发模式、优先级和消息的生存时间。JMS Client使用MessageProducer类来向一个目的地址（destination）发送消息。通常来讲，一个producer的目的地址在producer被建立时已经确认。
MessageProducer producer = session.createProducer();
void MessageProducer.send(Destination destination, Message message) throws JMSException;消息消费者是由会话创建的一个对象，，它用于接收发送到目的地的消息。客户端使用MessageProducer来向Destination发送消息。通过向Session的createConsumer()方法传入Queue或Topic来创建MessageConsumer。
消息的消费可以采用以下两种方法之一：
·同步消费：通过调用消费者的receive()方法从目的地中显式提取消息。receive()方法可以一直阻塞，直到消息到达。
·异步消费：客户可以为消费者注册一个消息监听器（MessageListener），以定义在消息到达时所采取的动作。这个接口主要实现了onMessage()方法。
Message：
JMS消息由以下三部分组成：消息头，消息属性，消息体。
消息头：包含了客户端和broker用来路由和识别消息的元数据。头字段包括：JMSDestination、JMSDeliveryMode、JMSTimeStamp等
消息属性：除了头字段定义的消息以外，Message接口包含了内置的设置来支持属性值。
消息体：JMS定义的消息类型有以下五种：
TextMessage：包含了一个java.lang.String
MapMessage：包含了一些列的name-value对，name是String，value是Java primitive类型。消息体中的条目可以被enumerator按照顺序访问，也可以自由访问。
BytesMessage：包含了一个不间断的字节流。
StreamMessage：包含了一个Java Primitive流对象，这个流可以顺序读取和填充。
ObjectMessage：包含了一个可序列化的Java对象
2.3 JMS Interfaces
JMS基于一套通用的消息概念。每个JMS消息域（PTP和Pub/Sub）也都定义了一套自己概念的接口。JMS通用接口则提供了不依赖于PTP和Pub/Sub消息域的能力。Classic API是JMS 1.x版本的API，Simplified API是JMS 2.0版本的API。
这些对象之间的关系如下图所示：
JMS Classic API：
JMS Simplified API：
legacy point-to-point-specific API：
legacy pub/sub-specific API：
开发一个消息客户端的一般步骤：
1.使用一个ConnectionFactory创建JMS连接（Connection）
2.使用一个连接创建一个或者多个JMSSession
3.使用Session创建所需的Message Producers和Message Consumers
4.告知Connection开始传递消息
2.4 JMS的可靠性机制
2.4.1 确认（Acknowledge）
JMS消息只有在被确认之后，才认为已经被成功的消费了。消息的成功消费通常包含三个阶段：客户接收消息、客户处理消息和消息被确认。在事务性会话中，当一个事务被提交的时候，确认自动发生。在非事务性会话中，消息何时被确认取决于创建会话时的应答模式。该参数有以下三个可选值：
Session.AUTO_ACKNOWLEDGE:当客户成功的从receive方法返回的时候，或者从MessageListener.onMessage方法成功返回的时候，会话自动确认客户收到的消息。
Session.CLIENT_ACKNOWLEDGE:客户通过消息的acknowledge方法确认消息。在这种模式中，虽然调用的是Message类上的方法，但是确认是在会话层（Session）上进行的。确认一个被消费的消息将自动确认所有已被会话消费的消息。例如，如果一个消息消费者消费了10个消息，然后确认第1个消息，那么所有10个消息都被确认。
Session.DUPS_ACKNOWLEDGE:这个选项让会话延迟发送消息的确认。如果JMS失败，则可能导致消息重复发送，因此只能在消息的消费者容忍消息时使用。它的好处在于通过最小化会话确认消息所作的工作来减少会话的负荷。如果是重复的消息，那么JMS provider必须把消息头的JMSRedelivered字段设置为true。几种消息确认方式性能分析如下：
| 确认模式 | 描述 |
| SESSION_TRANSACTED | 可靠的消息确认方式，执行事务提交时，一次确认这个事务中所有已消费的消息，性能良好 |
| CLIENT_ACKNOWLEDGE | 允许客户端一次确认多条已消费消息，性能良好 |
| AUTO_ACKNOWLEDGE | 默认的消息确认机制，性能较慢 |
| DUPS_OK_ACKNOWLEDGE | 当客户端缓冲区达到预取上限的50%时，发出确认。在消息确认的标准方式中，是最快的一种。 |
| INDIVIDUAL_ACKNOWLEDGE | 每消费一条消息，确认一次，性能很差 |
| optimizeAcknowledge | 严格意义上不能算作确认方式，它同AUTO_ACKNOWLEDGE确认方式一起工作。当预取上限的65%消息被消费时，发出一条确认。是最快的一种默认方式 |
2.4.2 持久性（Persistent）
JMS支持以下两种消息提交模式：
PERSISTENT：用于严格的不能丢失的消息。broker收到消息后先将消息持久化存储在本地磁盘中，然后生产者进行确认。然后再分发给消费者。当消息被消费者确认后，会对broker发出确认，broker收到消费者的确认才会从磁盘中删除消息。及时遭遇到系统崩溃，broker重启后也可以从磁盘中恢复所有未被消费的消息。
NON-PERSISTENT：用于可以允许偶尔有消息丢失的场合。消息不需要保存到本地磁盘，消息存储和分发全部都是在内存中进行的，处理速度比PERSISTENT要快很多。但是当broker系统崩溃是，内存的消息会丢失。
默认情况下：queue是persistent的，topic是non-persistent
根据测试结果：NON-PERSISTENT要比PERSISTENT快两个数量级。所以根据使用场合，定制消息传输模式，对性能至关重要！
2.4.3 优先级（Priority）
可以使用消息优先级来指示JMS provider首先提交紧急的消息。优先级分10个级别，从0（最低）到9（最高）。如果不指定优先级，默认级别是4。需要注意的是，JMS provider并不一定（Best Effort）严格按照优先级的顺序提交消息。
2.4.4 本地事务
在一个JMS客户端，可以使用本地事务来组合消息的发送和接收。
JMS Session接口提供了commit()和rollback()方法。事务提交意味着生产的所有消息被发送，消费的所有消息被确认；事务回滚意味着生产的所有消息被销毁，消费的所有消息被恢复并重新提交，除非它们已经过期。事务性的会话总是牵涉到事务处理中，commit或rollback方法一旦被调用，一个事务就结束了，而另一个事务被开始。关闭事务性会话将回滚其中的事务。需要注意的是，如果使用请求/回复机制，即发送一个消息，同时希望在同一个事务中等待接收该消息的回复，那么程序将被挂起，因为知道事务提交，发送操作才会真正执行。
需要注意的还有一个，消息的生产和消费不能包含在同一个事务中。
Author：忆之独秀
Email：[email protected]
注明出处：http://blog.csdn.net/lavorange/article/details/57567967