RabbitMQ精讲1：主流MQ对比，为什么选择RabbitMQ
目录
前言
1. 主流消息中间件介绍——ActiveMQ
1.1 特点
衡量一个MQ的指标，主要有三个方面：服务性能、数据存储、集群架构
1.2 ActiveMQ架构模式
Masrer-Slave模式
NetWork模式
1.3 ActiveMQ小结ActiveMQ优点：
ActiveMQ缺点：
2. 主流消息中间件介绍——Kafka
2.1 特点
2.2 kafka架构模式
2.3 kafka小结
kafka优点：
kafka缺点：
3. 主流消息中间件介绍——RocketMQ
3.1 RocketMQ特点：
3.2 RocketMQ集群架构模式
RocketMQ集群拓扑
3.3 RocketMQ小结
RocketMQ优点：
RocketMQ缺点：
4. 为什么选择RabbitMQ？
5. 主流消息中间件介绍——RabbitMQ
5.1 RabbitMQ特点
5.2 RabbitMQ的集群架构
6. 入门RabbitMQ核心概念
互联网大厂为什么选择RabbitMQ？
RabbiMQ的高性能是如何做到的？
什么是AMQP高级消息队列协议？
AMQP核心概念是什么？
RabbitMQ整体架构模型是什么样子的？
RabbitMQ消息是如何流转的？
前言
消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。今天主要来介绍了下几大主流消息中间件的区别与联系。
1. 主流消息中间件介绍——ActiveMQ
ActiveMQ是由Apache出品，ActiveMQ是一个完全支持JMS1.1和J2EE 1.4规范的JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。
1.1 特点
ActiveMQ
- ActiveMQ是Apache出品，最流行的，能力强劲的开源消息总线，并且它是一个完全支持JMS规范的消息中间件
- 其丰富的API、多种集群构建模式使得他成为业界老牌消息中间件，在中小型企业中应用广泛!
- MQ衡量指标：服务性能、数据存储、集群架构。
ActiveMQ现在用的比较少，因为ActiveMQ相比其他的MQ的性能来说比较一般。现如今高并发、大数据的应用场景随处可见。如果这时候在MQ的选择上，那么ActiveMQ就显得力不从心了。
衡量一个MQ的指标，主要有三个方面：服务性能、数据存储、集群架构
- 服务性能：ActiveMQ的性能不是特别好，面对超大规模并发时候，总是会出现各种各样的小问题，比如阻塞，消息堆积过多，产生一些延迟等等一些问题。
- 数据存储：ActiveMQ默认采用KahaDB内存存储方式。也可以采用一些高性能的存储方式，比如：google的LevelDb 基于内c存的。如果是为了保证消息的可靠，也可以采用mysql或者oracle数据库。
- 集群架构：ActiveMQ流行那么多年，与其他组件集成的Api也是十分完善的。如果不是特别大的并发场景下，ActiveMQ也是一个不错的选择。因为ActiveMQ的集群架构模式也是十分好。
1.2 ActiveMQ架构模式
ActiveMQ架构模式
Masrer-Slave模式
主备模式，利用Zookeeper进行两个或多个节点的协调。其中的主节点是对外提供服务的，而另外的从节点启动着，但是不对外提供服务。当主节点挂掉，利用Zookeeper进行一个高可用的切换，将Salve节点切换成主节点，继续对外提供服务。
NetWork模式
本质是两组主备模式的集成，中间用NewWork网关，做一个连接配置，就可以实现分布式集群。
1.3 ActiveMQ小结
ActiveMQ优点：
- 跨平台(JAVA编写与平台无关，ActiveMQ几乎可以运行在任何的JVM上)
- 可以用JDBC：可以将数据持久化到数据库。虽然使用JDBC会降低ActiveMQ的性能，但是数据库一直都是开发人员最熟悉的存储介质
- 支持JMS规范：支持JMS规范提供的统一接口
- 支持自动重连和错误重试机制
- 有安全机制：支持基于shiro，jaas等多种安全配置机制，可以对Queue/Topic进行认证和授权
- 监控完善：拥有完善的监控，包括WebConsole，JMX，Shell命令行，Jolokia的RESTful API
- 界面友善：提供的WebConsole可以满足大部分情况，还有很多第三方的组件可以使用，比如hawtio
ActiveMQ缺点：
- 社区活跃度不及RabbitMQ高
- 根据其他用户反馈，会出莫名其妙的问题，会丢失消息
- 目前重心放到activemq6.0产品Apollo，对5.x的维护较少
- 不适合用于上千个队列的应用场景
2. 主流消息中间件介绍——Kafka
Apache Kafka是一个分布式消息发布订阅系统。
它最初由LinkedIn公司基于独特的设计实现为一个分布式的日志提交系统(a distributed commit log)，之后成为Apache项目的一部分。Kafka性能高效、可扩展良好并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。
2.1 特点
Kafka
kafka是LinkedIn开源的分布式发布-定于消息系统，目前归属于Apache顶级项目。
Kafka主要特点是给予Pull的模式来处理消费消息，追求高吞吐量，一开始的目的就是用于日志收集和传输。
0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。这里可以看出kafka只关注吞吐量。
因此，在使用kafka的时候，注意业务是否允许消息重复、丢失、错误等。如果允许的话，kafka是最合适的。因为它的性能是最高的。即使在廉价的服务器上，也能支持单机每秒100k条以上的数据量。所以说它的性能是非常好的。kafka仅仅使用内存进行存储，只要有足够的内存，就能够足够大的吞吐量。因为kafka并没有在磁盘上进行读写。
- 快速持久化：可以在O(1)的系统开销下进行消息持久化；
- 高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；
- 完全的分布式系统：Broker、Producer和Consumer都原生自动支持分布式，自动实现负载均衡；
- 支持同步和异步复制两种高可用机制；
- 支持数据批量发送和拉取；
- 零拷贝技术(zero-copy)：减少IO操作步骤，提高系统吞吐量；
- 数据迁移、扩容对用户透明；
- 无需停机即可扩展机器；
- 其他特性：丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制
2.2 kafka架构模式
kafka架构模式
主要依赖Zookeeper进行协调管理，每一个kafka可以进行副本复制，也就是数据同步。
假如说：有一条数据落在第一个节点上，那么就会进行repilicate 复制，这样在运行中每个节点就有一份数据，一共就有三分数据。如果说其中一台宕机，也能从另外两个节点中获取数据。
部署方案建议：跨机房部署。即使有一台机子宕机，在数据上也是没有问题的。如果在整个地点宕机了。那么我们的数据也就丢失了。这也是大公司需要考虑的异地灾备。当然kafka主要关注性能的，对于数据的可靠性关注并高。
2.3 kafka小结
kafka优点：
- 客户端语言丰富：支持Java、.Net、PHP、Ruby、Python、Go等多种语言；
- 高性能：单机写入TPS约在100万条/秒，消息大小10个字节；
- 提供完全分布式架构，并有replica机制，拥有较高的可用性和可靠性，理论上支持消息无限堆积；
- 支持批量操作；
- 消费者采用Pull方式获取消息。消息有序，通过控制能够保证所有消息被消费且仅被消费一次；
- 有优秀的第三方KafkaWeb管理界面Kafka-Manager；
- 在日志领域比较成熟，被多家公司和多个开源项目使用。
kafka缺点：
- Kafka单机超过64个队列/分区时，Load时会发生明显的飙高现象。队列越多，负载越高，发送消息响应时间变长；
- 使用短轮询方式，实时性取决于轮询间隔时间；
- 消费失败不支持重试；
- 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
- 社区更新较慢。
3. 主流消息中间件介绍——RocketMQ
RocketMQ
RocketMQ是阿里开源的消息中间件，目前也已经孵化为Apache顶级项目。用Java语言实现，在设计时参考了Kafka，并做出了自己的一些改进，消息可靠性上比Kafka更好。RocketMQ在阿里内部被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。
3.1 RocketMQ特点：
- 保证消息的顺序性，消息按顺序消费。
- 提供了丰富的拉取和处理模式。
- 高效的订阅者，也可以进行水平扩展。
- 承载上亿级别的消息堆积能力。
3.2 RocketMQ集群架构模式
- Master-Slave（主从）模式
- 双Master模式。
- 双主双从模式。
- 多主多从模式。
- 一主多从模式。
RocketMQ集群拓扑
阿里觉得Zookeeper性能太低，自己搭建了NameServer，这个NameServer代码也十分精简，一共也就几百行代码。有兴趣可以去读源码。
3.3 RocketMQ小结
RocketMQ优点：
- 单机支持1万以上持久化队列；
- RocketMQ的所有消息都是持久化的，先写入系统PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，而访问时，直接从内存读取。
- 模型简单，接口易用（JMS的接口很多场合并不太实用）；
- 性能非常好，可以允许大量堆积消息在Broker中；
- 支持多种消费模式，包括集群消费、广播消费等；
- 各个环节分布式扩展设计，支持主从和高可用；
- 开发度较活跃，版本更新很快。
RocketMQ缺点：
- 支持的 客户端语言不多，目前是Java及C++，其中C++还不成熟
- 维护RocketMQ需要专业的团队
- 商业版收费，有许多功能是不对外提供的。
- 没有在MQ核心里实现JMS等接口
4. 为什么选择RabbitMQ？
- ActiveMQ，性能不是很好，因此在高并发的场景下，直接被pass掉了。它的Api很完善，在中小型互联网公司可以去使用。
- kafka，主要强调高性能，如果对业务需要可靠性消息的投递的时候。那么就不能够选择kafka了。但是如果做一些日志收集呢，kafka还是很好的。因为kafka的性能是十分好的。
- RocketMQ，它的特点非常好。它高性能、满足可靠性、分布式事物、支持水平扩展、上亿级别的消息堆积、主从之间的切换等等。MQ的所有优点它基本都满足。但是它最大的缺点：商业版收费。因此它有许多功能是不对外提供的。
那么说完这三种MQ还有没有其他MQ能够选择呢？有的，也是这次学习的MQ——RabbitMQ。
5. 主流消息中间件介绍——RabbitMQ
RabbitMQ于2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
5.1 RabbitMQ特点
RabbitMQ特点
- RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。
- AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
- AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
- RabbitMQ的可靠性是非常好的，数据能够保证百分之百的不丢失。可以使用镜像队列，它的稳定性非常好。所以说在我们互联网的金融行业。对数据的稳定性和可靠性要求都非常高的情况下，我们都会选择RabbitMQ。当然没有kafka性能好，但是要比AvtiveMQ性能要好很多。也可以自己做一些性能的优化。
- RabbitMQ可以构建异地双活架构，包括每一个节点存储方式可以采用磁盘或者内存的方式。
5.2 RabbitMQ的集群架构
RabbitMQ的集群架构
- 图中说的就是，我们可以采用三个节点作为RabbitMQ的一组集群，当然可以有许多组。节点与节点之间采用mirror queue。基于这种方式，能够保证数据百分之百的不丢失。
- 前端可以去做负载均衡，比如负载均衡组件：HA-proxy ，进行TCP级别的负载。
- 如果想做一个高可用的话，就需要借助keepAlived做一个高可用的配置。
- 比如前端加一个虚拟的VIP，通过VIP路由到指定的负载均衡组件，再有它路由到RabbtMQ的某一个节点。
这就是整个RabbitMQ集群架构。
能够实现非常完善，高可用并且性能也十分好，稳定性超强。并且有各种集群恢复手段。
比如:某一个节点挂了，或者某个磁盘损坏了，它也能进行一个消息修复。
6. 入门RabbitMQ核心概念
RabbitMQ
RabbitMQ 是一个开源的消息代理和队列服务器，用来通过普通协议在完全不同的应用之间共享数据（RabbitMQ能够实现跨语言跨平台的机制，），RabbitMQ是使用Erlang语言来编写的，并且RabbitMQ是基于AMQP协议的。
仅仅通过上面一句话，相信大家一定有很多疑惑和问题。
- RabbitM成熟度到底怎么样？
- 业界使用度怎么样？哪些大厂在使用？为什么？
- 包括RabbitMQ到底都有哪些特点?
- RabbitMQ为什么要用Erlang语言去编写？
- 什么是AMQP协议？AMQP协议里面的具体的规范又是什么？
我相信大家跟我一样都会有这样的疑惑。那么我们一起来学习一RabbitMQ吧。
互联网大厂为什么选择RabbitMQ？
业界使用度怎么样？哪些大厂在使用？为什么？都有哪些优点？
- 据我了解：滴滴、美团、去哪儿、头条…
这些互联网大厂都会采用RabbitMQ作为它底层的消息通信的一个基础组件。根本原因：
- 开源、性能优秀、稳定性保障
- 提供可靠性消息投递模式（confirm）、返回模式（return）
- 与SpringAMQP完美的整合、扩展性变得更强、API丰富
- 集群模式丰富、表达式配置、HA（高可用）模式、镜像队列模型
- 保证数据不丢失的前提下做到高可靠性、可用性
RabbiMQ的高性能是如何做到的？
原因就在于它使用了Erlang语言，Erlang语言最初在于交换机领域的架构模式，这样使得RabbitQ在Broker之间进行数据交互的性能是非常优秀的。
- 还有一点也是取决于作者，RabbitMQ开发的作者在开发RabbitMQ之间，先用Erlang语言做了一个简单的交换机，然后他惊奇的发现：Erlang的优点：Erlang有着和原生Socket一样好的延迟效果。
- 相信大家接触过Socket的朋友，对它的有怎样的性能有一定的了解。像我们耳熟能详的RPC通信框架。比如说：dubbo，它底层就是采用了Netty，Netty无非就是网络编程中的高性能之王，它无非就是一个Socket。
- 基于这个特点呢，我们就有了一个充分的选择RabbitMQ的理由。其实我们选择RabbitMQ的时候，有一个主要的考量目标就是：当消息入到RabbtMQ节点上的时候，RabbitMQ的延迟以及响应。
什么是AMQP高级消息队列协议？
AMQP全称：Advanced Message Queuing Protocol（高级消息队列协议）
AMQP定义：是具有现代特征的二进制协议。是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。
它就类似于Java中的JMS。是比较上层的规范，基于这个规范可以开发出各种各项的消息中间件。
AMQP协议模型
- Pubilsher application：生产者应用 生产的消息，扔到Server端。
- Server：指的就是RabbitMQ的节点
- Virtual host:虚拟主机，比较上层的一个路由，类似于路由器这么一个概念。后续介绍
- Exchange:交换机，生产者直接将消息投递到Exchange中。但是要经历3个过程 -》server->Virtual host->Exchange
先确定将消息发送到哪台服务器，那么就需要先去建立连接，设置一些地址等等。
- 第二层，投递到哪个Virtual host 需要定义。
- 第三层，投递到哪个Exchange也需要定义。
再看Consumer application 消费者的应用端，消费端只需要监听Message Queue，当队列中有消息的时候，就拿出来消费。因此在Exchange和Message Queue之间有绑定的关系存在，后续详细介绍。
AMQP核心概念是什么？
AMQP核心概念
- server: 又称Broker,接收客户端的链接，实现AMQP实体服务
- Connection: 链接，应用程序与Broker的网络连接
AMQP核心概念
- Channel:网络信道，几乎所有的操作（数据的读、写）都在Channel中进行，Channel是进行消息读写的通道。客户端可建立多个Channel，每个Channel代表一个会话任务。
AMQP核心概念
- Message：消息，服务器和应用程序之间传送的数据，由Properties和Body组成。Properties可以对消息进行修饰，比如消息的优先级、延迟等高级特性；Body则就是消息体内容。
AMQP核心概念
- Virtual host:虚拟地址，用于进行逻辑隔离，最上层的消息路由。一个Virtual host 里面可以有若干个Exchange和Queue，同一个Virtual Host里面不能有相同名称的Exchange和Queue。一种逻辑概念，类似Redis的逻辑数据库。用来划分具体的服务。
- Exchange：交换机，接收消息，根据路由键转发消息到绑定的队列
标题
- Binding:Exchange 和Queue之间的虚拟连接，Binding中可以包含routing key
- Routing key:一个路由股则，虚拟机可用它来确定如何路由一个特定消息。
- Queue:也称为message Queue,消息队列，保存消息并将它们转发给消费者。
以上核心概念先有一个大概的认知，以后会详细介绍。
RabbitMQ整体架构模型是什么样子的？
RabbitMQ整体架构模型
- 生产者把消息投递到Exchange,Exchange投递到Queue.
- 因此我们的生产者只需要关注把消息投递到指定的Exchange即可,我们的消费者只需要监听指定Queue即可。就是这么简单的机制。
- 通过图我们也能看到，生产者不需要关注投递到哪个队列，消费也不需要关注是从哪个Exchange上来的，这两块没有耦合的情况。主要是应为Exchange和Queue有一个绑定的关系。
RabbitMQ消息是如何流转的？
RabbitMQ消息是如何流转的
生产者publisher application 生产消息Message投递到Exchange上，Exchange绑定MessageQueue，可以绑定过多个MessageQueue，为什么三个队列只有其中一个队列收到了消息呢？主要是由于Exchange是有一个路由功能的。这个路由就是routing key,这个路由有两个非常关键的点，
- 第一个：你的消息是需要发送到哪个Exchange。
- 第二个：你发消息的时候需要带上routing key，然后通过Exchange 和 MessageQueue 建立一个绑定关系，通过路由key把消息路由到一个指定的队列上。然后我们的消费端直接监听队列就行了，就可以消费了。