为什么需要使用消息中间件
在介绍消息中间件之前，我们先来看一个故事：
老王的睡前故事：
在很久很久以前，小明隔壁有个姓王的邻居，姑且就叫隔壁老王吧。隔壁老王有个大女儿，名叫王兰花秀丽，秀丽从小就爱听老王讲睡前故事，每晚在入睡前都要老王讲了睡前故事才能睡的得着。但某一天秀丽到了外地去上大学，老王为了能给秀丽讲故事，只能通过打电话的方式进行，如下：
但是有时候可能由于秀丽的手机信号不好或者没电等情况，导致老王只能不停的联系，直到电话打通为止。老王内心：我能怎么办，我也很绝望啊。虽然秀丽可能会比较晚才能听到故事，但是这个过程问题也不大。直到某一天，老王的二女儿王兰花独秀也到了外地去上学，独秀也爱听老王讲睡前故事。老王没办法，只能也给独秀打电话。但是这样就会导致独秀等电话的时间需要等很久，因为老王得先给秀丽讲完再给独秀讲。有时候遇到信号不好的情况就更麻烦了，这样的话天天都需要耗到很晚，老王也感觉到身体好像被掏空：
经历了几个晚上后，老王想着天天这样子不行啊，搞得身体一天不如一天。于是作为老程序员的老王冥思苦想，想到了一个类似于消息中间件的办法，那就是注册一个微信公众号。老王只需要把每天的睡前故事放到这个公众号里，让两个女儿来订阅这个公众号就行了。那么两个女儿不仅能够不用等待谁先听完故事，老王也不用天天熬夜了，而且大家都觉得这个公众号讲的故事很好，于是来听老王讲故事的人越来越多，从此老王走上人生巅峰，真是可带劲了：
借助了微信公总号来讲故事后，老王不需要再去关心有多少人要听故事，老王只需要把故事放到公众号里。想听故事的人只需要有网络有微信来订阅这个公众号即可，这样不仅读者能随时随地听故事，而老王也不需要被讲故事的事情而耗费太多的时间。这个故事就是诠释了消息中间件为我们解决的一些问题。
我们再来举个栗子，例如我们现在有一个登录系统。我们实现的是通过短信验证码进行登录，所以在用户登录时登录系统需要去调用短信服务发送短信验证码给用户。除了短信服务外，还有一个积分服务，用于加载用户的积分信息。用户登录时还需要记录日志，这里就需要调用一个日志服务。随着系统的发展，登录时需要调用的服务可能越来越多。那么就意味着，用户进行一个简简单单的登录操作，就需要等待各种服务调用完成后才能登录上去，让登录的时间变得越来越长，万一有哪一个服务卡住了那么用户的登录也会卡住，所以登录系统和相关服务的耦合就很高，导致用户仅是进行登录时就得花费很多与登录功能本身不相关的时间。这就是通过服务调用让其他系统感知事件发生：
消息中间件就是用于解除这种耦合的，当用户发送登录请求并通过验证后，消息中间件就可以马上通知用户登录成功，而给其他服务投递消息的工作就由消息中间件去完成，也就是会进行一个异步处理，而用户是无感知的，不会拖慢用户的登录时间。通过消息中间件解耦服务调用：
消息中间件带来的好处：
- 解耦系统
- 异步通知
- 横向扩展
- 安全可靠
- 顺序保证
- ...
消息中间件概述
什么是中间件：
- 非底层操作系统软件，非业务应用软件，不是直接给最终用户使用的，不能直接给客户带来价值的软件统称为中间件。
什么是消息中间件：
- 关注于数据的发送和接收，利用高效可靠的异步消息传递机制集成分布式系统
消息中间件流程图：
说到消息中间件不得不提一下JMS规范，什么是JMS规范：
- Java消息服务（Java Message Service）即JMS，是一个Java平台中关于面向消息中间件的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
同样的，涉及到消息中间件也需要对AMQP协议有一定的了解，什么是AMQP协议：
- AMQP（advanced message queuing protocol）是一个提供统一消息服务的应用层标准协议，基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言条件的限制。
JMS和AMQP对比：
常见消息中间件对比：
| 名称 | 描述 | 特性 |
|---|---|---|
| ActiveMQ | ActiveMQ 是Apache出品的，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4 规范的JMS Provider实现，尽管JMS规范出台已经是很久的事情了，但是JMS在当今的J2EE应用中仍然扮演着特殊的地位 | 多种语言和协议编写客户端。语言：Java、C/C++、C#、Ruby、Perl、Python、PHP。应用协议：OpenWire、Stomp、REST、WS、Notification、XMPP、AMQP。完全支持JMS1.1和J2EE 1.4规范（持久化、XA消息、事务）。支持虚拟主题、组合目的以及镜像队列等 |
| RabbitMQ | RabbitMQ是一个开源的AMQP实现，服务端用Erlang语言编写。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗 | 支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript。是AMQP模型的完整实现（vhost、Exchange、Binding、Routing Key 等）。支持事务及发布确认等特性，可对消息进行持久化 |
| Kafka | Kafka是一种高吞吐量的分布式发布订阅消息系统，是一个分布式的、分区的、可靠的分布式日志存储服务。它通过一种独一无二的设计提供了一个消息系统的功能 | 通过O(1)复杂度的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。 |
综合评价：
JMS
JMS相关概念：
- 提供者：实现JMS规范的消息中间件服务器
- 客户端：发送或接收消息的应用程序
- 生产者/发布者：创建发送消息的客户端
- 消费者/订阅者：接收并处理消息的客户端
- 消息：应用程序之间传递的数据内容
- 消息模式：在客户端之间传递消息的方式，JMS中定义了主题和队列两种模式
JMS消息模式：
队列模式：
- 客户端包括生产者和消费者
- 队列中的消息只能被一个消费者消费
- 消费者可以随时消费队列中的消息
队列模式示意图：
主题模式：
- 客户端包括发布者和订阅者
- 主题中的消息被所有订阅者消费
- 消费者不能消费订阅之前就发送到主题中的消息
主题模式示意图：
JMS编码接口：
- ConnectionFactory 连接工厂，用于创建连接到消息中间件的连接工厂对象
- Connection 连接，代表了应用程序和服务器之间的通信链路
- Destination 目的地，指定消息发布和接收的地点，包括队列或主题
- Session 会话，表示一个单线程的上下文，用于发送和接收消息
- MessageConsumer 消息消费者，由Session来创建，用于接收发送到目标的消息
- MessageProducer 消息生产者，由Session来创建，用于发送消息到目标
- Message 消息体，是在消费者和生产者之间传送的对象，一般由消息头 、 一组消息属性以及 一个消息体组成
JMS编码接口之间的关系：
原文地址：http://blog.51cto.com/zero01/2120351