浅显易懂的消息队列和JMS规范

转自 http://blog.51cto.com/zero01/2120351
有些知识进行了补充。

为什么需要使用消息中间件
在介绍消息中间件之前，我们先来看一个故事：

老王的睡前故事：

在很久很久以前，小明隔壁有个姓王的邻居，姑且就叫隔壁老王吧。隔壁老王有个大女儿，名叫王兰花秀丽，秀丽从小就爱听老王讲睡前故事，每晚在入睡前都要老王讲了睡前故事才能睡的得着。但某一天秀丽到了外地去上大学，老王为了能给秀丽讲故事，只能通过打电话的方式进行，如下：

但是有时候可能由于秀丽的手机信号不好或者没电等情况，导致老王只能不停的联系，直到电话打通为止。老王内心：我能怎么办，我也很绝望啊。虽然秀丽可能会比较晚才能听到故事，但是这个过程问题也不大。直到某一天，老王的二女儿王兰花独秀也到了外地去上学，独秀也爱听老王讲睡前故事。老王没办法，只能也给独秀打电话。但是这样就会导致独秀等电话的时间需要等很久，因为老王得先给秀丽讲完再给独秀讲。有时候遇到信号不好的情况就更麻烦了，这样的话天天都需要耗到很晚，老王也感觉到身体好像被掏空：

经历了几个晚上后，老王想着天天这样子不行啊，搞得身体一天不如一天。于是作为老程序员的老王冥思苦想，想到了一个类似于消息中间件的办法，那就是注册一个微信公众号。老王只需要把每天的睡前故事放到这个公众号里，让两个女儿来订阅这个公众号就行了。那么两个女儿不仅能够不用等待谁先听完故事，老王也不用天天熬夜了，而且大家都觉得这个公众号讲的故事很好，于是来听老王讲故事的人越来越多，从此老王走上人生巅峰，真是可带劲了：

借助了微信公总号来讲故事后，老王不需要再去关心有多少人要听故事，老王只需要把故事放到公众号里。想听故事的人只需要有网络有微信来订阅这个公众号即可，这样不仅读者能随时随地听故事，而老王也不需要被讲故事的事情而耗费太多的时间。这个故事就是诠释了消息中间件为我们解决的一些问题。

我们再来举个栗子，例如我们现在有一个登录系统。我们实现的是通过短信验证码进行登录，所以在用户登录时登录系统需要去调用短信服务发送短信验证码给用户。除了短信服务外，还有一个积分服务，用于加载用户的积分信息。用户登录时还需要记录日志，这里就需要调用一个日志服务。随着系统的发展，登录时需要调用的服务可能越来越多。那么就意味着，用户进行一个简简单单的登录操作，就需要等待各种服务调用完成后才能登录上去，让登录的时间变得越来越长，万一有哪一个服务卡住了那么用户的登录也会卡住，所以登录系统和相关服务的耦合就很高，导致用户仅是进行登录时就得花费很多与登录功能本身不相关的时间。这就是通过服务调用让其他系统感知事件发生：

消息中间件就是用于解除这种耦合的，当用户发送登录请求并通过验证后，消息中间件就可以马上通知用户登录成功，而给其他服务投递消息的工作就由消息中间件去完成，也就是会进行一个异步处理，而用户是无感知的，不会拖慢用户的登录时间。通过消息中间件解耦服务调用：

消息中间件带来的好处：

解耦系统
异步通知
横向扩展
安全可靠
顺序保证
…

消息中间件概述

什么是中间件：

非底层操作系统软件，非业务应用软件，不是直接给最终用户使用的，不能直接给客户带来价值的软件统称为中间件。

什么是消息中间件：

关注于数据的发送和接收，利用高效可靠的异步消息传递机制集成分布式系统
消息中间件流程图：

说到消息中间件不得不提一下JMS规范，什么是JMS规范：

Java消息服务（Java Message Service）即JMS，是一个Java平台中关于面向消息中间件的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
同样的，涉及到消息中间件也需要对AMQP协议有一定的了解，什么是AMQP协议：

AMQP（advanced message queuing protocol）是一个提供统一消息服务的应用层标准协议，基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言条件的限制。

JMS和AMQP对比：

JMS

JMS相关概念：

提供者： 实现JMS规范的消息中间件服务器
客户端： 发送或接收消息的应用程序
生产者/发布者： 创建发送消息的客户端
消费者/订阅者： 接收并处理消息的客户端
消息： 应用程序之间传递的数据内容
消息模式： 在客户端之间传递消息的方式，JMS中定义了主题和队列两种模式

JMS消息模式：

队列模式：

客户端包括生产者和消费者
消息生产者生产消息发送到 queue 中，然后消息消费者从 queue 中取出并且消费消息。
消息被消费以后，queue 中不再有存，所以消费者不可能消费到已经被消费的消息。
Queue 支持存在多个消费者， 但是对一个消息而言， 只会有一个消费者可以消费、 其它的则不能消费此消息了。
当消费者不存在时， 消息会一直保存， 直到有消费消费

队列模式示意图：

主题模式：

客户端包括发布者和订阅者
消息生产者将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消息。
和点对点方式不同， 发布到 topic 的消息会被所有订阅者消费。
当生产者发布消息， 不管是否有消费者。 都不会保存消息
一定要先有消息的消费者， 后有消息的生产者。

主题模式示意图：

PTP 和 PUB/SUB 简单对比

JMS编码接口：

ConnectionFactory 连接工厂，用于创建连接到消息中间件的连接工厂对象
Connection 连接，代表了应用程序和服务器之间的通信链路
Destination 目的地，指定消息发布和接收的地点，包括队列或主题
Session 会话，表示一个单线程的上下文，用于发送和接收消息
MessageConsumer 消息消费者，由Session来创建，用于接收发送到目标的消息
MessageProducer 消息生产者，由Session来创建，用于发送消息到目标
Message 消息体，是在消费者和生产者之间传送的对象，一般由消息头 、 一组消息属性以及 一个消息体组成
JMS编码接口之间的关系：