一、JMS经典模式详解

JMS即Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM，Message oriented Middleware）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。与具体平台无关的API，绝大多数MOM提供商都支持。

它类似于JDBC(Java Database Connectivity)。

1. JMS消息：

消息是JMS中的一种类型对象，由两部分组成：报文头和消息主体。

报文头包括消息头字段和消息头属性。字段是JMS协议规定的字段，属性可以由用户按需添加。

JMS报文头全部字段：

消息主体则携带着应用程序的数据或有效负载。

根据有效负载的类型来划分，可以将消息分为几种类型：

1. 简单文本(TextMessage)
2. 可序列化的对象(ObjectMessage)
3. 属性集合(MapMessage)
4. 字节流(BytesMessage)
5. 原始值流(StreamMessage)
6. 无有效负载的消息(Message)。

2. 体系架构

JMS由以下元素组成：

1. JMS供应商产品
   JMS接口的一个实现。该产品可以是Java的JMS实现，也可以是非Java的面向消息中间件的适配器。
2. JMS Client
   生产或消费基于消息的Java的应用程序或对象。
3. JMS Producer
   创建并发送消息的JMS客户。
4. JMS Consumer
   接收消息的JMS客户。
5. JMS Message
   包括可以在JMS客户之间传递的数据的对象
6. JMS Queue
   缓存消息的容器。消息的接受顺序并不一定要与消息的发送顺序相同。消息被消费后将从队列中移除。
7. JMS Topic
   Pub/Sub模式

3. 对象模型

1. ConnectionFactory 接口（连接工厂）
   用户用来创建到JMS提供者的连接的被管对象。JMS客户通过可移植的接口访问连接，这样当下层的实现改变时，代码不需要进行修改。管理员在JNDI名字空间中配置连接工厂，这样，JMS客户才能够查找到它们。根据消息类型的不同，用户将使用队列连接工厂，或者主题连接工厂。
2. Connection 接口（连接）
   连接代表了应用程序和消息服务器之间的通信链路。在获得了连接工厂后，就可以创建一个与JMS提供者的连接。根据不同的连接类型，连接允许用户创建会话，以发送和接收队列和主题到目标。
3. Destination 接口（目标）
   目标是一个包装了消息目标标识符的被管对象，消息目标是指消息发布和接收的地点，或者是队列，或者是主题。JMS管理员创建这些对象，然后用户通过JNDI发现它们。和连接工厂一样，管理员可以创建两种类型的目标，点对点模型的队列，以及发布者/订阅者模型的主题。
4. Session 接口（会话）
   表示一个单线程的上下文，用于发送和接收消息。由于会话是单线程的，所以消息是连续的，就是说消息是按照发送的顺序一个一个接收的。会话的好处是它支持事务。如果用户选择了事务支持，会话上下文将保存一组消息，直到事务被提交才发送这些消息。在提交事务之前，用户可以使用回滚操作取消这些消息。一个会话允许用户创建消息，生产者来发送消息，消费者来接收消息。
5. MessageConsumer 接口（消息消费者）
   由会话创建的对象，用于接收发送到目标的消息。消费者可以同步地（阻塞模式），或（非阻塞）接收队列和主题类型的消息。
6. MessageProducer 接口（消息生产者）
   由会话创建的对象，用于发送消息到目标。用户可以创建某个目标的发送者，也可以创建一个通用的发送者，在发送消息时指定目标。
7. Message 接口（消息）
   是在消费者和生产者之间传送的对象，也就是说从一个应用程序传送到另一个应用程序。一个消息有三个主要部分：
   1、消息头（必须）：包含用于识别和为消息寻找路由的操作设置。
   2、 一组消息属性（可选）：包含额外的属性，支持其他提供者和用户的兼容。可以创建定制的字段和过滤器（消息选择器）。
   3、一个消息体（可选）：允许用户创建五种类型的消息（文本消息，映射消息，字节消息，流消息和对象消息）。

4. 模式

Java消息服务应用程序结构支持两种模式：

1. 点对点也叫队列模式
2. 发布/订阅模式

1、在点对点或队列模型下
一个生产者向一个特定的队列发布消息，一个消费者从该队列中读取消息。这里，生产者知道消费者的队列，并直接将消息发送到消费者的队列，概括为：

• 一条消息只有一个消费者获得
• 生产者无需在接收者消费该消息期间处于运行状态，接收者也同样无需在消息发送时处于运行状态。
• 每一个成功处理的消息要么自动确认，要么由接收者手动确认。

2、发布/订阅模式

• 支持向一个特定的主题发布消息。
• 0或多个订阅者可能对接收特定消息主题的消息感兴趣。
• 发布者和订阅者彼此不知道对方。
• 多个消费者可以获得消息

在发布者和订阅者之间存在时间依赖性。

• 发布者需要建立一个主题，以便客户能够订阅。
• 订阅者必须保持持续的活动状态以接收消息，否则会丢失未上线时的消息。
• 对于持久订阅，订阅者未连接时发布的消息将在订阅者重连时重发。

5. 传递方式

JMS有两种传递消息的方式。

标记为NON_PERSISTENT的消息最多投递一次，而标记为PERSISTENT的消息将使用暂存后再转送的机理投递。

如果一个JMS服务下线，持久性消息不会丢失，等该服务恢复时再传递。默认的消息传递方式是非持久性的。使用非持久性消息可能降低内务和需要的存储器，当不需要接收所有消息时使用。

6. 供应商

开源软件：

1. Apache ActiveMQ
2. RabbitMQ
3. RocketMQ
4. JBoss 社区所研发的 HornetQ
5. Joram
6. Coridan的MantaRay
7. The OpenJMS Group的OpenJMS
   专有的供应商包括：
8. BEA的BEA WebLogic Server JMS
9. TIBCO Software的EMS
10. GigaSpaces Technologies的GigaSpaces
11. Softwired 2006的iBus
12. IONA Technologies的IONA JMS
13. SeeBeyond的IQManager（2005年8月被Sun Microsystems并购）
14. webMethods的JMS±
15. my-channels的Nirvana
16. Sonic Software的SonicMQ
17. SwiftMQ的SwiftMQ
18. IBM的WebSphere MQ

二、JMS在应用集群中的问题

生产中应用基本上都是以集群部署的。在Queue模式下，消息的消费没有什么问题，因为不同节点的相同应用会抢占式地消费消息，这样还能分摊负载。

如果使用Topic广播模式？对于一个消息，不同节点的相同应用都会收到该消息，进行相应的操作，这样就重复消费了。。。


方案一：选择Queue模式，创建多个一样的Queue，每个应用消费自己的Queue。
弊端：浪费空间，生产者还需要关注下游到底有几个消费者，违反了“解耦”的初衷。
方案二：选择Topic模式，在业务上做散列，或者通过分布式锁等方式来实现不同节点间的竞争。
弊端：对业务侵入较大，不是优雅的解决方法。

ActiveMQ通过“虚拟主题”解决了这个问题。
生产中似乎需要结合这两种模式：即不同节点的相同应用间存在竞争，会部分消费（P2P），而不
同的应用都需要消费到全量的消息（Topic）模式。这样就可以避免重复消费。

三、JMS与AMQP的区别

JMS是JEE平台的标准消息传递API。它可以在商业和开源实现中使用。每个实现都包括一个JMS服务器，一个JMS客户端库，以及用于管理消息传递系统的其他特定于实现的组件。 JMS提供程序可以是消息传递服务的独立实现，也可以是非JMS消息传递系统的桥梁。

JMS客户端API是标准化的，因此JMS应用程序可在供应商的实现之间移植。但是：

1. 底层消息传递实现未指定，因此JMS实现之间没有互操作性。除非存在桥接技术，否则想要共
   享消息传递的Java应用程序必须全部使用相同的JMS实现。
2. 如果没有供应商特定的JMS客户端库来启用互操作性，则非Java应用程序将无法访问JMS。
3. AMQP 0-9-1是一种消息传递协议，而不是像JMS这样的API。任何实现该协议的客户端都可以
   访问支持AMQP 0-9-1的代理。
4. 协议级的互操作性允许以任何编程语言编写且在任何操作系统上运行的AMQP 0-9-1客户端都
   可以参与消息传递系统，而无需桥接不兼容的服务器实现。