RabbitMQ
RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。
AMQP ：Advanced Message Queue，高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。
RabbitMQ 最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展 性、高可用性等方面表现不俗。
RabbitMQ优缺点
优点:
erlang语言开发，性能极其好，延时很低；
吞吐量到万级，MQ功能比较完备;
而且开源提供的管理界面非常棒，用起来很好用;
社区相对比较活跃，几乎每个月都发布几个版本在国内一些互联网公司近几年用rabbitmq也比较多一些;
缺点:
RabbitMQ相较kafka确实吞吐量会低一些，这是因为他做的实现机制比较重;
erlang语言本身带来的问题。很难读源码，很难定制和掌控。
rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。
RabbitMQ架构图
强烈推荐大家看看rabbitmq的中文文档
架构图解释
RabbitMQServer： 也叫brokerserver，它是一种传输服务。
他的角色就是维护一条 从Producer到Consumer的路线，保证数据能够按照指定的方式进行传输。
Producer： 消息生产者，如图A、B、C，数据的发送方。
消息生产者连接RabbitMQ服务器然后将消息投递到Exchange。
Consumer：消息消费者，如图1、2、3，数据的接收方。
消息消费者订阅队列，RabbitMQ将Queue中的消息发送到消息消费者。
Exchange：生产者将消息发送到Exchange（交换器），由Exchange将消息路由到一个或多个Queue中（或者丢弃)。
Exchange并不存储消息。RabbitMQ中的Exchange有
direct、fanout、topic、headers四种类型，每种类型对应不同的路由规则。
Queue：（队列）是RabbitMQ的内部对象，用于存储消息。
消息消费者就是通过订阅队列来获取消息的，RabbitMQ中的消息都只能存储在Queue中
生产者生产消息并最终投递到Queue中消费者可以从Queue中获取消息并消费。多个消费者可以订阅同一个Queue，
这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。
RoutingKey：生产者在将消息发送给Exchange的时候，一般会指定一个routingkey，来指定这个消息的路由规则
而这个routingkey需要与ExchangeType及bindingkey联 合使用才能最终生效。
在ExchangeType与bindingkey固定的情况下（在正常使用时一般这些内容都是固定配置好的）
我们的生产者就可以在发送消息给Exchange时，通过 指定routingkey来决定消息流向哪里。
RabbitMQ为routingkey设定的长度限制为255 bytes。
__________________________________________________________________________________________________
*下面某方面比较重要.b比如Channels可以开启confirm模式进而做数据维护
Connection： （连接）：Producer和Consumer都是通过TCP连接到RabbitMQServer 的。
以后我们可以看到，程序的起始处就是建立这个TCP连接.
Channels： （信道）：它建立在上述的TCP连接中。数据流动都是在Channel中进行
的。也就是说，一般情况是程序起始建立TCP连接，第二步就是建立这个Channel。
VirtualHost：权限控制的基本单位
一个VirtualHost里面有若干Exchange和MessageQueue，以及指定被哪些user使用
我来一句话总结下我理解消息中间件
类似于厨师做完菜只管把菜送给服务员就可以忙自己的事了,服务员再对这些菜进行配送,这样做呢,厨师和顾客的耦合就降下来了,而且厨师做菜和配送也不再是一个处理流程,做了异步.当做的菜太多了,我们也可以把它放一会或者让厨师别做了或做别的去或者增加服务员数量.
另外这里说一下我用RabbitMQ的原因
1.语言无关,什么语言都可以,对我们这边很多使用不同语言开发的项目比较友好,大家都可以用
2.低时延,并发能力高,他是基于erlang语言开发,erlang内部对多线程做了很多优化,然后他对操作系统的调度优化基本相当于实现了自己的进程管理一样. 进程非常轻量，短时间能快速创建和销毁，并且切换代价小；Erlang 进程间通讯使用消息，而不是多线程编程中常用的锁机制，没有等待锁的时间消耗。
3.管理界面比较好看,功能强大
4.最主要的是文档比较完善,我们之前团队一直用的都是这个RabbitMQ
