JMS规范，AMQP谢协议详解

JMS 规范
1.1. JMS经典模式详解
1.1.1. JMS即Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间 件（MOM，Message oriented Middleware）的API，用于在两个应用程序之间，或分布式系统中发送 消息，进行异步通信。与具体平台无关的API，绝大多数MOM提供商都支持。
1.1.2. 类似于JDBC(Java Database Connectivity)。
1.2. JMS消息
1.2.1. 消息是JMS中的一种类型对象，由两部分组成：报文头和消息主体
· 报文头
· 包括消息头字段和消息头属性,字段是JMS协议规定的字段，属性可以由用户按需添加。
· JMS报文头全部字段
· JMSDestination 字段包含了消息要发送到的目的地
· JMSDeliveryMode 字段包含了消息在发送的时候指定的投递方式
· JMSMessageId 该字段包含了服务器发送的每一个消息标识
· JMSTimestamp 该字段包含了消息封装完成要发往服务器的时间,不是真正想服务器发送的时间,因为真正的发送时间,可能由于事务或者客户端消息排队而延后
· JMSCorrlationId 客户端使用该字段的值于另一条消息关联.典型的场景是使用该字段将响应消息和请求消息关联
· JMSCorrlationId 可以包含如下值
· 服务器规定的消息Id
· 应用指定的字符串
· 服务器原生的byte[] 值
· JMSReplyTo 该字段包含了在客户端发送消息时指定的Destination,即对该消息的 响应应该发送到该字段指定的Destination。设置了该字段值的消息一般 望收到一个响应。
· JMSRedelivered 如果这个字段是true，则告知消费者应用这条消息已经发送过了，消费端 应用应该小心别重复处理了。
· JMSType 消息发送的时候用于标识该消息的类型。具体有哪些类型，由JMS实现厂商决定。
· JMSExpiration 发送消息时，其到期时间将计算为send方法上指定的生存时间值与当前 GMT值之和。 从send方法返回时，消息的JMSExpiration标头字段包含此 值。 收到消息后，其JMSExpiration标头字段包含相同的值。
· JMSPriority JMS定义了一个十级优先级值，最低优先级为0，最高优先级为9。 此外， 客户端应将优先级0-4视为正常优先级，将优先级5-9视为快速优先级。 JMS不需要服务器严格执行消息的优先级排序； 但是，它应该尽力在普通 消息之前传递加急消息。
· 消息主体
· 消息主体则携带着应用程序的数据或有效负载。
· 根据有效负载的类型来划分，可以将消息分为几种类型：
· 简单文本(TextMessage)
· 可序列化的对象(ObjectMessage)
· 属性集合(MapMessage)
· 字节流(BytesMessage)
· 原始值流(StreamMessage)
· 无有效负载的消息(Message)。
1.3. 体系架构
1.3.1. JMS供应商产品 JMS接口的一个实现。该产品可以是Java的JMS实现，也可以是非Java的面向消息中间件的适 配器。
1.3.2. JMS Client 创建或消费基于消息的Java的应用程序或对象
1.3.3. JMS Producer 创建并发送消息的JMS客户(生产者)
1.3.4. JMS Consumer 接受消息的JMS客户(消费者)
1.3.5. JMS Message 包括可以再JMS客户之前传递的数据对象
1.3.6. JMS Queue 缓存消息的容器,消息接受顺序并不一定要与消息发送顺序相同,消息消费后会从队列中移除
1.3.7. JMS Topic Pub/Sub模式。
1.4. 对象模型
1.4.1. ConnectionFactory 接口（连接工厂）
· 用户用来创建到JMS提供者的连接的被管对象。JMS客户通过可移植的接口访问连接，这样当下层的实现改变时，代码不需要进行修改。管理员在JNDI名字空间中配置连接工厂，这样，JMS客户才能够查找到它们。根据消息类型的不同，用户将使用队列连接工厂，或者主题连接工厂。
1.4.2. Connection 接口（连接）
· 连接代表了应用程序和消息服务器之间的通信链路。在获得了连接工厂后，就可以创建一个与JMS提供者的连接。根据不同的连接类型，连接允许用户创建会话，以发送和接收队列和主题到目标
1.4.3. Destination 接口（目标）
· 目标是一个包装了消息目标标识符的被管对象，消息目标是指消息发布和接收的地点，或者是队列，或者是主题。JMS管理员创建这些对象，然后用户通过JNDI发现它们。和连接工厂一样，管理员可以创建两种类型的目标，点对点模型的队列，以及发布者/订阅者模型的主题。
1.4.4. Session 接口（会话）
· 表示一个单线程的上下文，用于发送和接收消息。由于会话是单线程的，所以消息是连续的，就是说消息是按照发送的顺序一个一个接收的。会话的好处是它支持事务。如果用户选择了事务支持，会话上下文将保存一组消息，直到事务被提交才发送这些消息。在提交事务之前，用户可以使用回滚操作取消这些消息。一个会话允许用户创建消息，生产者来发送消息，消费者来接收消息。
1.4.5. MessageProducer 接口（消息生产者）
· 由会话创建的对象，用于发送消息到目标。用户可以创建某个目标的发送者，也可以创建一个通用的发送者，在发送消息时指定目标。
1.4.6. MessageConsumer 接口（消息消费者）
· 由会话创建的对象，用于接收发送到目标的消息。消费者可以同步地（阻塞模式），或（非阻塞）接收队列和主题类型的消息。
1.4.7. Message 接口（消息）
· 是在消费者和生产者之间传送的对象，也就是说从一个应用程序传送到另一个应用程序。一个消息有三个主要部分：
· 消息头（必须）：包含用于识别和为消息寻找路由的操作设置。
· 一组消息属性（可选）：包含额外的属性，支持其他提供者和用户的兼容。可以建定制的字段和过滤器（消息选择器）。
· 一个消息体（可选）：允许用户创建五种类型的消息（文本消息，映射消息，字节消息，流消息和对象消息）。
1.5. Java消息服务应用程序结构支持两种模式：
1.5.1. 点对点也叫队列模式 一个生产者向一个特定的队列发布消息，一个消费者从该队列中读取消息。这里，生产者知道消费者的队列，并直接将消息发送到消费者的队列，概括为：
· 一条消息只有一个消费者获得
· 生产者无需在接收者消费该消息期间处于运行状态，接收者也同样无需在消息发送时处于运行状态。
· 每一个成功处理的消息要么自动确认，要么由接收者手动确认。
1.5.2. 发布/订阅模式
· 支持向一个特定的主题发布消息。
· 0或多个订阅者可能对接收特定消息主题的消息感兴趣。
· 发布者和订阅者彼此不知道对方。
· 多个消费者可以获得消息
· 在发布者和订阅者之间存在时间依赖性。
· 发布者需要建立一个主题，以便客户能够订阅。
· 订阅者必须保持持续的活动状态以接收消息，否则会丢失未上线时的消息。
· 对于持久订阅，订阅者未连接时发布的消息将在订阅者重连时重发。
1.6. 传递方式
1.6.1. JMS有两种传递消息的方式
1.6.2. 标记为NON_PERSISTENT的消息最多投递一次，而标记为PERSISTENT的消息将使用暂存后再转送的机理投递。
1.6.3. 如果一个JMS服务下线，持久性消息不会丢失，等该服务恢复时再传递。默认的消息传递方式是非持久性的。使用非持久性消息可能降低内务和需要的存储器，当不需要接收所有消息时使用。
1.7. 供应商
1.7.1. 开源软件
· 1. Apache ActiveMQ
· 2. RabbitMQ
· 3. RocketMQ
· 4. JBoss 社区所研发的 HornetQ
· 5. Joram
· 6. Coridan的MantaRay
· 7. The OpenJMS Group的OpenJMS
1.7.2. 专有的供应商
· 1. BEA的BEA WebLogic Server JMS
· 2. TIBCO Software的EMS
· 3. GigaSpaces Technologies的GigaSpaces
· 4. Softwired 2006的iBus 21
· 5. IONA Technologies的IONA JMS
· 6.SeeBeyond的IQManager（2005年8月被Sun Microsystems并购）
· 7. webMethods的JMS±
· 8. my-channels的Nirvana
· 9. Sonic Software的SonicMQ
· 10. SwiftMQ的SwiftMQ
· 11. IBM的WebSphere MQ
1.8. JMS在应用集群中的问题
1.8.1. 对于一个消息，不同节点的相同应用都会收到该消息，进行相应的操作，这样就重复消费了。。。 怎么解决
· 方案一：选择Queue模式，创建多个一样的Queue，每个应用消费自己的Queue。 弊端：浪费空间，生产者还需要关注下游到底有几个消费者，违反了“解耦”的初衷。
· 选择Topic模式，在业务上做散列，或者通过分布式锁等方式来实现不同节点间的竞争。 弊端：对业务侵入较大，不是优雅的解决方法。
· ActiveMQ通过“虚拟主题”解决了这个问题。
· 生产中似乎需要结合这两种模式：即不同节点的相同应用间存在竞争，会部分消费（P2P），而不同的应用都需要消费到全量的消息（Topic）模式。这样就可以避免重复消费。
1.9. 总结
1.9.1. JMS是JEE平台的标准消息传递API。它可以在商业和开源实现中使用。每个实现都包括一个JMS服务器，一个JMS客户端库，以及用于管理消息传递系统的其他特定于实现的组件。 JMS提供程序可以是消息传递服务的独立实现，也可以是非JMS消息传递系统的桥梁。
1.9.2. JMS客户端API是标准化的，因此JMS应用程序可在供应商的实现之间移植。但是：
· 1.底层消息传递实现未指定，因此JMS实现之间没有互操作性。除非存在桥接技术，否则想要共享消息传递的Java应用程序必须全部使用相同的JMS实现。
· 2.如果没有供应商特定的JMS客户端库来启用互操作性，则非Java应用程序将无法访问JMS。
· 3.AMQP0-9-1是一种消息传递协议，而不是像JMS这样的API。任何实现该协议的客户端都可以访问支持AMQP 0-9-1的代理。
· 4.协议级的互操作性允许以任何编程语言编写且在任何操作系统上运行的AMQP0-9-1客户端都可以参与消息传递系统，而无需桥接不兼容的服务器实现。

2. AMQP协议
   2.1. AMQP全称高级消息队列协议（Advanced Message Queuing Protocol），是一种标准，类似于JMS，兼容JMS协议。目前RabbitMQ主流支持AMQP 0-9-1，3.8.4版本支持AMQP 1.0。
   2.2. AMQP协议中的概念
   2.2.1. Publisher：消息发送者，将消息发送到Exchange并指定RoutingKey，以便queue可以接收到指定的消息。
   2.2.2. Consumer：消息消费者，从queue获取消息，一个Consumer可以订阅多个queue以从多个queue中接收消息。
   2.2.3. Server：一个具体的MQ服务实例，也称为Broker。
   2.2.4. Virtualhost：虚拟主机，一个Server下可以有多个虚拟主机，用于隔离不同项目，一个Virtual host通常包含多个Exchange、Message Queue。
   2.2.5. Exchange：交换器，接收Producer发送来的消息，把消息转发到对应的Message Queue中。
   2.2.6. Routingkey：路由键，用于指定消息路由规则（Exchange将消息路由到具体的queue中），通常需要和具体的Exchange类型、Binding的Routingkey结合起来使用。
   2.2.7. Bindings：指定了Exchange和Queue之间的绑定关系。Exchange根据消息的Routing key和 Binding配置（绑定关系、Binding、Routing key等）来决定把消息分派到哪些具体的queue中。这依 赖于Exchange类型。
   2.2.8. Message Queue：实际存储消息的容器，并把消息传递给最终的Consumer。
   2.3. 传输层架构
   2.3.1. 数据类型
   · Integers（数值范围1-8的十进制数字）：用于表示大小，数量，限制等，整数类型无符号的，可以在帧内不对齐。
   · Bits（统一为8个字节）：用于表示开/关值。
   · Short strings：用于保存简短的文本属性，字符串个数限制为255，8个字节
   · Long strings：用于保存二进制数据块。
   · Field tables：包含键值对，字段值一般为字符串，整数等。
   2.3.2. 协议协商
   · 在AMQP中，我们需要协商协议的一些特殊方面：
   · 1、 真实的协议和版本。服务器可能在同一个端口支持多个协议。
   · 2、 双方的加密参数和认证方式。这是功能层的一部分。
   · 3、 数据帧最大大小，通道数量以及其他操作限制。
   2.3.3. 数据帧界定
   · TCP/IP是流协议，没有内置的机制用于界定数据帧。现有的协议从以下几个方面来解决：
   · 1. 每个连接发送单一数据帧。简单但是慢。
   · 2. 在流中添加帧的边界。简单，但是解析很慢。
   · 3. 计算数据帧的大小，在每个数据帧头部加上该数据帧大小。这简单，快速，AMQP的选择。