RabbitMQ消息队列

RabbitMQ是一款在全球范围内使用非常广泛的开源消息队列中间件。它轻量级、易部署、并支持多种协议。它基于Erlang开发，天生拥有高并发的能力

1. 主流消息队列

（1）ActiveMQ

基于JAVA语言开发，其社区算是比较成熟，但是目前来说，ActiveMQ的性能比较差，而且版本迭代很慢

（2）RocketMQ

阿里出品，Java系开源项目，源代码可以直接阅读，可以定制自己公司的MQ，并且RocketMQ有阿里巴巴的实际业务场景的实战考验，RocketMQ社区活跃度相对较为一般，文档相对来说简单一些，接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码

（3）Kafka

由Scala和Java编写，其特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量，Kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集

（4）RabbitMQ

在吞吐量方面虽然稍逊于Kafka和RocketMQ ，但是由于它基于erlang开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为RabbitMQ基于erlang开发，所以国内很少有公司有实力做erlang源码级别的研究和定制。如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ一定是你的首选。如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，社区活跃度很高，何况几乎是全世界这个领域的事实性规范

（5）ZeroMQ

只是一个网络编程的Pattern库，将常见的网络请求形式（分组管理，链接管理，发布订阅等）模式化、组件化，简而言之socket之上、MQ之下。对于MQ来说，网络传输只是它的一部分，更多需要处理的是消息存储、路由、Broker服务发现和查找、事务、消费模式（ack、重投等）、集群服务

2. 各种不同消息队列的对比

(1) RabbitMQ/Kafka/ZeroMQ都能提供消息队列服务，但有很大的区别

(2) 在面向服务架构中通过消息代理（比如 RabbitMQ / Kafka等），使用生产者/消费者模式在服务间进行异步通信是一种比较好的思想

(3) ZeroMQ和RabbitMQ/Kafka 不同，它只是一个异步消息库，在套接字的基础上提供了类似于消息代理的机制。使用ZeroMQ的话，需要对自己的业务代码进行改造，不利于服务解耦

(4) RabbitMQ支持AMQP（二进制），STOMP（文本），MQTT（二进制），HTTP（里面包装其他协议）等协议，而Kafka使用自己的协议

(5) Kafka自身服务和消费者都需要依赖Zookeeper，RabbitMQ在有大量消息堆积的情况下性能会下降，Kafka不会，毕竟AMQP设计的初衷不是用来持久化海量消息的，而Kafka一开始是用来处理海量日志的

3. 消息队列中角色/名词

（1）Broker：

消息服务器，作为server提供消息核心服务

（2）Producer：

消息生产者，业务的发起方，负责生产消息传输给broker

（3）Consumer：

消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理

（4）Topic：

主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播

（5）Queue：

队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收

（6）Message：

消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

4. 消息队列中两种工作模式

（1）Point-to-Point

（2）Pub/Sub

5. 消息队列缺点

（1）系统可用性降低

（2）系统复杂性提高