前言
趁着国庆的空余时间写了一个RabbitMQ的专栏，不知道你们玩的开心不，我方正假期的一大半时间都去参加婚礼了，今年国庆结婚的同窗好多啊git
github地址：https://github.com/erlieStar/rabbitmq-examples
github
可能你在没学消息中间件以前都已经听过不少概念了，JMS，AMQP，ActiveMQ，RabbitMQ，Kafka，RocketMQ，一个消息中间件怎么能搞出怎么多概念？乱不乱啊，
别烦，本文从历史的角度帮你理清这些MQ和协议之间的关系。数据库
什么是消息中间件？
消息中间件属于分布式系统中的一个子系统，关注于数据的发送和接收，利用高效可靠的消息传递机制对分布式系统中的其他各个子系统经进行集成编程
消息中间件的使用场景
1.异步处理
非核心流程异步化，提升系统响应性能
服务器
原来用户注册一下可能得依次写数据库，发送邮件和短信后，才能提示用户注册成功
如今只要写数据库，写消息队列后就直接提示用户注册成功，发送邮件和短信是异步处理，提升了响应速度
2.应用解耦
系统不是强耦合，消息接受者能够随意增长，而不须要修改消息发送者的代码。消息发送者的成功不依赖消息接受者微信
若是库存系统出了问题，用户就不能正常下单，这是不合理的。能够经过消息队列来解耦。
当有新的系统如广告系统对用户的订单也感兴趣的时候，只须要从消息队列中拿消息便可，订单系统彻底不用改变
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.在 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 社区活跃度相对较为通常，不过也还能够，文档相对来讲简单一些。
Kafka 的特色其实很明显，就是仅仅提供较少的核心功能，可是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，并且分布式能够任意扩展。同时 Kafka 最好是支撑较少的 topic 数量便可，保证其超高吞吐量。Kafka 惟一的一点劣势是有可能消息重复消费，那么对数据准确性会形成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响能够忽略。Kafka自然适合大数据实时计算以及日志收集。
消息模型
若是让你设计一个消息队列？你会怎么实现呢？
可能你立马就会想到用队列，一边放，一边取。这其实就是消息队列常见的一种消息模型，队列模型
因此一个简单的消息队列用Redis中的List就能实现。固然Redis5.0版本以后针对消息队列这种场景专门设计了一个数据结构Streams。
队列模型有哪些缺点呢？
若是将一类消息发送给不一样的消费者，每一个消费者都要接收全量的消息，此时就很不方便。由于你要将相同的消息发送到不一样的队列，多一个消费者就得多发一份队列。这样生产者必须知道有多少个消费者，不利于解耦。
那么该如何解决这个问题呢？
想一想RabbitMQ的结构图
RabbitMQ并非直接把消息发送到队列中的，而是发送到Exchange中，Exchange和Queue进行关联，消息由Exchange根据规则发送到对应的队列。这样生产者和消费者完成了解耦。
还有哪一种方式能解决这种多消费者的问题呢？
答对了，就是发布订阅模型
RocketMQ和Kafka都是基于发布订阅模型实现的，RocketMQ的消息模型图以下
生产者是发布者，消费者是订阅者，消息是主题
为了提升消费的并行度，一类消息会被分发到多个队列中，在RocketMQ中叫Queue，在Kafka中叫作Partition（分区），都是相似的概念。
AMQP协议详解
前面说到消息中间件有2种协议，JMS和AMQP。JMS你能够类比为JDBC，搞了一套接口让不一样厂商来实现这个接口，可是这个协议设计的确实不够优雅，所以就不介绍这个协议了，除非你用ActiveMQ，否则学了真没啥用。详细说一下AMQP协议，毕竟如今用RabbitMQ的公司仍是不少的，要想学好RabbitMQ，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来阐述上面的概念。
本文分享自微信公众号 - Java识堂（erlieStar）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。