前言
可能你在没学消息中间件之前都已经听过很多概念了，JMS，AMQP，ActiveMQ，RabbitMQ，Kafka，RocketMQ，一个消息中间件怎么能搞出怎么多概念？乱不乱啊， 别烦，本文从历史的角度帮你理清这些MQ和协议之间的关系。
什么是消息中间件？
消息中间件属于分布式系统中的一个子系统，关注于数据的发送和接收，利用高效可靠的消息传递机制对分布式系统中的其余各个子系统经进行集成
消息中间件的使用场景
1.异步处理
非核心流程异步化，提高系统响应性能
原来用户注册一下可能得依次写数据库，发送邮件和短信后，才能提示用户注册成功 现在只要写数据库，写消息队列后就直接提示用户注册成功，发送邮件和短信是异步处理，提高了响应速度
2.应用解耦
系统不是强耦合，消息接受者可以随意增加，而不需要修改消息发送者的代码。消息发送者的成功不依赖消息接受者
rpc实现
消息队列实现 如果库存系统出了问题，用户就不能正常下单，这是不合理的。可以通过消息队列来解耦。 当有新的系统如广告系统对用户的订单也感兴趣的时候，只需要从消息队列中拿消息即可，订单系统完全不用改变
3.流量削峰
当上下游系统处理能力存在差距的时候，可以用消息队列进行缓冲
当有秒杀业务时，一下有大量请求涌入时，很可能造成系统瘫痪，此时可以用消息队列缓冲一下
4.日志处理
将消息队列用在日志处理中，比如Kafka可以用来解决大量日志传输的问题
5.消息通讯
消息队列一般都内置了高效的通信机制，因此也可以用于单纯的消息通讯，比如实现点对点消息队列或者聊天室等
消息中间件编年史
1.初见曙光 消息中间件其实诞生的很早，在互联网应用还是一片荒芜的年代，有个在美国的印度哥们Vivek Ranadive就设想了一种通用软件总线，采用发布订阅的模式，像主板上的总线一样供其他相应程序接入。他创办了一家公司Teknekron，实现了世界上第一个消息中间件The Information Bus(TIB)
2.各自为战 TIB受到了企业的欢迎，Teknekron的业务发展引起了当时最牛气的IT公司IBM的注意，于是他们也开始研发了自己消息队列软件，于是才有了后来的wesphere mq，微软也陆续加入了战团。由于商业壁垒，商业MQ供应商想要解决应用互通的问题，而不是去创建标准来实现不同MQ产品间的互通，或者允许应用程序更改MQ平台
3.劫制天下 为了打破这个壁垒，同时为了能够让消息在各个消息队列平台间互融互通， JMS (Java Message Service) 应运而生 。JMS 试图通过提供公共 Java API 的方式，隐藏单独 MQ 产品供应 商提供的实际接口，从而跨越了壁垒，以及解决了互通问题。从技术上讲， Java 应用程序只需 针对 JMS API 编程，选择合适的 MQ 驱动即可， JMS 会打理好其他部分 。ActiveMQ 就是 JMS 的 一种实现 。不过尝试使用单独标准化接口来胶合众多不同的接口，最终会暴露出问题，使得 应用程序变得更加脆弱 。所以急需一种新的消息通信标准化方案 。
4.一统江湖 4.在 2006 年 6 月，由 Cisco 、 Redhat 、iMatix 等联合制定了 AMQP 的公开标准，由此 AMQP 登上了历史的舞台 。它是应用层协议的一个开放标准，以解决众多消息中间件的需求和拓扑结 构问题 。它为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受 产品、开发语言等条件的限制 。
5.合久必分 LinkedIn在实现消息队列的时候觉得AMQP规范并不适合自己，所以Kafka并不支持AMQP协议。RocketMQ在实现上借鉴了Kakfa的思想，所以也不支持AMQP协议，并且你会发现在Kafka和RocketMQ中都有类似Topic和Consumer Group的概念，而这些概念在AMQP协议中是不存在的
如何选择消息中间件
- ActiveMQ 的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用。
- RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为 RabbitMQ 基于 erlang 开发，所以国内很少有公司有实力做erlang源码级别的研究和定制。如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ 一定是你的首选。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
- RocketMQ 阿里出品，Java 系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的MQ，并且 RocketMQ 有阿里巴巴的实际业务场景的实战考验。RocketMQ 社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些。还有就是阿里出台的技术，你得应对这个技术万一被抛弃，社区黄掉的风险，如果你们公司有技术实力我觉得用RocketMQ 挺好的
- Kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 Kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量。Kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略。Kafka天然适合大数据实时计算以及日志收集。
AMQP协议详解
前面说到消息中间件有2种协议，JMS和AMQP。JMS你可以类比为JDBC，搞了一套接口让不同厂商来实现这个接口，但是这个协议设计的确实不够优雅，因此就不介绍这个协议了，除非你用ActiveMQ，不然学了真没啥用。详细说一下AMQP协议，毕竟现在用RabbitMQ的公司还是很多的，要想学好RabbitMQ，AMQP协议是必须要清楚的。
AMQP协议模型 上图是AMQP协议中一个消息的流转过程，画的的很清楚，不详细介绍了。
AMQP核心概念
介绍一些AMQP协议常见的概念。
概念 | 解释 |
|---|---|
Server | 又称Broker，接受客户端的连接，实现AMQP实体服务 |
Connection | 一个网络连接，比如TCP/IP套接字连接 |
Channel | 多路复用连接中的一条独立的双向数据流通道。为会话提供物理传输介质 |
Message | 消息，服务器和应用程序之间传送的数据，由Properties和Body组成。Properties可以对消息进行修饰，比如消息的优先级，延迟等高级特性，Body则就是消息体内容 |
Virtual Host | 虚拟地址，用于进行逻辑隔离，最上层的消息路由。一个Virtual Host里面可以有若干个Exchange和Queue，同一个Virtual Host里面不能有相同名称的Exchange或Queue |
Binding | 消息队列和交换器之间的关联 |
Routing Key | 一个消息头，交换器可以用这个消息头决定如何路由某条消息 |
Message Queue | 消息队列，用来保存消息直到发送给消费者 |
如果有用过ActiveMQ和RabbitMQ，对上面的名词一定不会陌生。后面一篇文章就结合RabbitMQ来阐述上面的概念。
参考资料
[1]《Java工程师面试突击第1季-中华石杉老师》 [2]《RabbitMQ实战指南》 [3]《Java互联网架构师-享学课堂》
