1.消息中间件在分布式系统中的作用介绍
消息中间件是在分布式系统中完成消息的发送和接收的基础软件。
1.1消息中间件可利用高效可靠的消息传递机制进行平台无关的数据交流，
并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息
排队模型，可以在分布式环境下扩展进程间的通信。
通过消息中间件，应用程序或组件之间可以进行可靠的异步通讯，从而
降低系统之间的耦合度，提高系统的可扩展性和可用性。
1.2通过使用消息中间件对Dubbo服务间的调用进行解耦
总结：
1.分布式服务间的异步通信
2.对Dubbo服务间的调用进行解耦
3.通过异步提高程序响应速度
异步通讯、解耦、并发缓冲
2.JMS（Java Message Service）
JMS是JavaEE中的一个关于消息的规范，是一套与具体平台无关的API。
JMS元素
JMS提供者—-连接面向消息中间件的，JMS接口的一个实现。
JMS客户——生产或消费消息的基于Java的应用程序或对象。
JMS生产者—-创建并发送消息的JMS客户。
JMS消费者—-接收消息的JMS客户。
JMS消息——可以在JMS客户之间传递的数据的对象
JMS队列——一个容纳那些被发送的等待阅读的消息的区域。
JMS主题——一种支持发送消息给多个订阅者的机制。
JMS应用程序接口
ConnectionFactory（连接工厂）——用户用来创建到JMS提供者的连接的被管对象。
Connection（连接）——————-连接代表了应用程序和消息服务器之间的通信链路。
Destination（目标）——————-消息发布和接收的地点，或者是队列，或者是主题。
MessageProducer（消息生产者）—–由会话创建的对象，用于发送消息到目标。
MessageConsumer（消息消费者）—-由会话创建的对象，用于接收发送到目标的消息。
Message（消息）———————-是在消费者和生产者之间传送的对象。
Session（会话）————————表示一个单线程的上下文，用于发送和接收消息。
2.1JMS消息模型
1、点对点或队列模型
JMS 点对点队列模型特点：
1、消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
2、消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。
3、Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
2、发布者/订阅者模型
JMS 发布/订阅模型特点：
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。
发布到topic的消息会被所有订阅者消费。
在此我向大家推荐一个Java高级群 ：725633148 里面会分享一些资深架构师录制的视频录像：（有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构）等这些成为架构师必备的知识体系 进群马上免费领取，目前受益良多！
3.MQ对比与选择
实现了JMS规范的消息中间件产品
ActiveMQ、RocketMQ、RabbitMQ、HornetQ……
| ActiveMQ | RabbitMQ | RocketMq | Joram | HornetQ | OpenMQ | MuleMQ | SonicMQ | ZeroMQ |
关注度 | 高 | 高 | 中 | 中 | 中 | 中 | 低 | 低 | 中 |
成熟度 | 成熟 | 成熟 | 比较成熟 | 比较成熟 | 比较成熟 | 比较成熟 | 新产品无成功案例 | 成熟 | 不成熟 |
所属社区/公司 | Apache | Mozilla Public License | Alibaba | OW2 | Jboss | Sun | Mule | Progress |
|
社区活跃度 | 高 | 高 | 中 | 中 | 中 | 低 | 高 | 低 | 低 |
文档 | 多 | 多 | 中 | 多 | 中 | 中 | 少 | 少 | 中 |
特点 | 功能齐全，被大量开源项目使用 | 由于Erlang 语言的并发能力，性能很好 | 各个环节分布式扩展设计，主从 HA；支持上万个队列；多种消费模式；性能很好 |
| 在 Linux 平台上直接调用操作系统的 AIO，性能得到很大的提升 |
| 性能非常 好，与 MuleESB 无缝整合 | 性能优越的商业 MQ | 低延时，高性能，最高 43万条消息每秒 |
授权方式 | 开源 | 开源 | 开源 | 开源 | 开源 | 开源 | 商业 | 商业 | 开源 |
开发语言 | Java | Erlang | Java | Java | Java | Java | Java | Java | C |
支持的协议 | OpenWire、 STOMP、 REST、XMPP、 AMQP | AMQP | 自己定义的一 套(社区提供 JMS–不成熟) | JMS | JMS | JMS | JMS | JMS | TCP、UDP |
客户端支持语言 | Java、C、 C++、 Python、 PHP、 Perl、.net等 | Java、C、 C++、 Python、 PHP、Perl 等 | Java C++（不成熟）
| Java | Java | Java | Java | Java、C、 C++、.net | python、 java、 php、.net 等 |
持久化 | 内存、文件、数据库 | 内存、文件 | 磁盘文件 | 内存、文件 | 内存、文件 | 内存、文件 | 内存、文件 | 内存、文件、数据库 | 在消息发送端保存 |
事务 | 支持 | 不支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 不支持 |
集群 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 不支持 |
负载均衡 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 | 不支持 |
管理界面 | 一般 | 好 | 无社区有 web console 实现 | 一般 | 无 | 一般 | 一般 | 好 | 无 |
部署方式 | 独立、嵌入 | 独立 | 独立 | 独立、嵌入 | 独立、嵌入 | 独立、嵌入 | 独立 | 独立 | 独立 |
评价 | 优点： 成熟的产品，已经在很多公司得到应用（非大规模场景）。有较多的文档。各种协议支持较好，有多重语言的成熟的客户端；缺点： 根据其他用户反馈，会出莫名其妙的问题，切会丢 失消息。 其重心放到 activemq6.0 产品—apollo上去了，目前社区不活跃，且对 5.x 维护较少； Activemq 不适合用于上千个队列的应用场景 | 优点： 由于 erlang语言的特性，mq性能较好；管理界面较丰富，在互联网公司也有较大规模的应用；支持amqp系诶，有多中语言且支持 amqp 的客 户端可用
缺点： erlang语言难度较 大。集群不支持动态扩展。 | 优点： 模型简单，接口易用（JMS的接口很多场合并不太实 用）。在阿里大规模应用。目前支付宝中的余额宝等新兴产 品均使用 rocketmq。集群规模大概在 50 台左右，单日处理消息上 百亿；性能非常好，可以大量堆 积消息在 broker 中；支持多种消费，包括集群消费、广播消费等。开发度较活跃，版本 更新很快。
缺点： 产品较新，文档比较缺乏。 没有在 mq 核心中去实现JMS 等接口，对已有系统而言不能兼容。阿里内部还有一套未开源 的 MQ API，这一层API可以将上层应用和下层 MQ 的实现解耦（阿里内部有多个mq的实现，如 notify、 |
|
|
|
|
|
|
|
|
| metaq1.x， metaq2.x， rocketmq 等），使得下面mq可以很方便的进行切换和升级而对应用无任何影响，目前这一套东西未开源 |
|
|
|
|
|
|