消息队列的技术选型

1 消息队列简介

消息队列是分布式系统中重要的中间件，在高性能、高可用、低耦合等系统架构中扮演着重要作用。分布式系统可以借助消息队列的能力
轻松实现以下功能:

1. 解耦:将一个流程的上游和下游拆开，上游专注生产消息，下游专注处理消息。
2. 流量削锋：当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的”载体”，在下游有能力处理的时候，再进行分发与处理。
3. 缓冲:应对流量突然上涨，消息队列可以扮演一个缓冲器的作用，保护下游服务使其可以根据实际的消费能力处理消息。
4. 异步:上游发送消息后可以马上返回，下游可以异步处理消息。
5. 冗余:保留历史消息，处理失败或当出现异常时可以进行重试或者回溯防止丢失。
6. 广播:一个上游生产的消息轻松被多个下游服务处理。

2 选型原则

我们在做技术选型的时候我们的出发点就是要选择一个最适合自己应用场景的产品，现在流行的几款开源消息队列（ActiveMQ、RabbitMQ、RocketMQ、Kafka、还有最近兴起的Pulsar等等）没有好坏之分，因为不好用的产品早就被淘汰掉了，能经过时间的洗礼生存下来的一定有其特有的特点和功能，所以本篇文章只说其特点，不分优劣。

3 ActiveMQ

官网：https://activemq.apache.org/

Apache ActiveMQ诞生于2003年，是Apache软件基金会所研发的开放源代码消息中间件；由于ActiveMQ是一个纯Java程序，因此只需要操作系统支持Java虚拟机，ActiveMQ便可执行；ActiveMQ经过20年的发展已经非常成熟。

3.1 优点

1. 成熟
2. 本完全支持JMS1.1和J2EE 1.4规范(持久化,XA消息,事务)
3. Spring Framework
4. 集群 (Clustering)
5. 支持的编程语言包括：C、C++、C#、Delphi、Erlang、Adobe Flash、Haskell、Java、JavaScript、Perl、PHP、Pike、Python和Ruby
6. 协议支持包括：OpenWire、REST、STOMP、WS-Notification、MQTT、XMPP以及AMQP

3.2 缺点

1. 性能稍弱（具体需要根据实际情况测试，大概是万级吞吐量）；
2. 没有大规模实践经验，不适合用于上千个队列的应用场景；
3. 根据其他用户反馈，会出莫名其妙的问题，会丢失消息；
4. 目前重心放到activemq6.0产品Apollo，对5.x的维护较少；

4 RabbitMQ

官网:https://www.rabbitmq.com/

1. Rabbit科技有限公司开发了RabbitMQ，并提供对其的支持。起初，Rabbit科技是LSHIFT和CohesiveFT在2007年成立的合资企业，2010年4月被VMware旗下的SpringSource收购。RabbitMQ在2013年5月成为GoPivotal的一部分。
2. RabbitMQ是一套开源（MPL）的消息队列服务软件，是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的 Erlang 写成

4.1优点

1. 异步消息传递：支持多种消息协议，消息队列，传送确认，灵活的路由到队列，多种交换类型；
2. 支持几乎所有最受欢迎的编程语言：Java，C，C ++，C＃，Ruby，Perl，Python，PHP等等；
3. 可以部署为高可用性和吞吐量的集群;
4. 跨多个可用区域和区域进行联合；
5. 可插入的身份验证，授权，支持TLS和LDAP；
6. 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件；
7. 提供了一个易用的用户界面，使得用户可以监控和管理消息Broker，社区活跃度高。

4.2缺点

1. erlang开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复bug，不利于做二次开发和维护；
2. RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重；
3. 需要学习比较复杂的接口和协议，学习和维护成本较高。

5 RocketMQ

官网：https://rocketmq.apache.org/zh/

1. RocketMQ是阿里巴巴在2012年开发的分布式消息中间件，专为万亿级超大规模的消息处理而设计，具有高吞吐量、低延迟、海量堆积、顺序收发等特点。它是阿里巴巴双十一购物狂欢节和众多大规模互联网业务场景的必备基础设施。在同一年，阿里巴巴正式开源了RocketMQ的第一个版本。
2. RocketMQ作为一款纯java、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。

5.1 优点

1. 支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型；
2. 在一个队列中可靠的先进先出（FIFO）和严格的顺序传递；
3. 支持拉（pull）和推（push）两种消息模式；
4. 单一队列百万消息的堆积能力；
5. 支持多种消息协议，如 JMS、MQTT 等；
6. 分布式高可用的部署架构,满足至少一次消息传递语义；
7. 提供 docker 镜像用于隔离测试和云集群部署；
8. 提供配置、指标和监控等功能丰富的 Dashboard。

5.2 缺点

1. 支持的客户端语言不多，目前是java及c++，其中c++不成熟
2. 社区活跃度一般没有在 mq 核心中去实现JMS等接口，有些系统要迁移需要修改大量代码

5.3 总结：

天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ在稳定性上可能更值得信赖，这些业务场景在阿里双11已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择RocketMQ。

6 Kafka

官网:https://kafka.apache.org/

1. Kafka 是消息传递系统之王。它由 LinkedIn 于 2011 年创建，并在 Confluent 的支持下得到了广泛的传播。
2. Confluent 已向开源社区发布了许多新功能和附加组件，例如用于模式演化的 Schema Registry，用于从其他数据源轻松流式传输的 Kafka Connect 等。
3. 数据库到 Kafka，Kafka Streams 进行分布式流处理，最近使用 KSQL 对 Kafka topic 执行类似 SQL 的查询等等。
4. Kafka 快速，易于安装，非常受欢迎，可用于广泛的范围或用例。
5. 从开发人员的角度来看，尽管 Apache Kafka 一直很友好，但在操作运维方面却是一团糟。

6.1 优点：

1. 高吞吐、低延迟：kakfa 最大的特点就是收发消息非常快，kafka 每秒可以处理几十万条消息，它的最低延迟只有几毫秒；
2. 高伸缩性：每个主题(topic) 包含多个分区(partition)，主题中的分区可以分布在不同的主机(broker)中；
3. 持久性、可靠性：Kafka 能够允许数据的持久化存储，消息被持久化到磁盘，并支持数据备份防止数据丢失，Kafka 底层的数据存储是基于 Zookeeper 存储的，Zookeeper 我们知道它的数据能够持久存储；
4. 容错性：非常高，kafka是分布式的，一个数据多个副本，某个节点宕机，Kafka 集群能够正常工作；
5. 消息有序：消费者采用Pull方式获取消息，消息有序，通过控制能够保证所有消息被消费且仅被消费一次；
6. 有优秀的第三方Kafka Web管理界面Kafka-Manager，在日志领域比较成熟，被多家公司和多个开源项目使用；
7. 功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用。

6.2 缺点：

1. Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长；
2. 使用短轮询方式，实时性取决于轮询间隔时间；
3. 消费失败不支持重试；
4. 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
5. 社区更新较慢。

6.3 总结：

Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。大型公司建议可以选用，如果有日志采集功能，肯定是首选kafka。

7 Pulsar

官网：https://pulsar.apache.org/

1. Apahce Pulasr是一个企业级的发布-订阅消息系统，最初是由雅虎开发，是下一代云原生分布式消息流平台；
2. 2012年pulsar在Yahoo内部开发,2016年开源并捐献给Apache,2018成为Apache顶级项目；
3. Apahce Pulasr集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。

7.1 优点

1. 更多功能：Pulsar Function、多租户、Schema registry、n 层存储、多种消费模式和持久性模式等；
2. 更大的灵活性：3 种订阅类型（独占，共享和故障转移），用户可以在一个订阅上管理多个 topic；
3. 易于操作运维：架构解耦和 n 层存储；
4. 与 Presto 的 SQL 集成，可直接查询存储而不会影响 broker；
5. 借助 n 层自动存储选项，可以更低成本地存储；

7.2 缺点

1. 相对缺乏支持、文档和案例；
2. n 层体系结构导致需要更多组件：BookKeeper；
3. 插件和客户端相对 Kafka 较少;
4. 云中的支持较少，Confluent 具有托管云产品。
5. 总之pulsar比较新，用得企业比较少，社区不够完善

---

---

8 表格对比（不包括pulsar）

特性	Kafka	RocketMQ	RabbitMQ	ActiveMQ
单机 吞吐量	10万级别，吞吐量高是kafka最大的优点	10万级，RocketMQ 也是可以支撑高吞吐的 MQ	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	万级，吞吐量比RocketMQ和Kafka要低了一个数量级
支持 主题数	百级，topic 达到百级时吞吐量会大幅度下降，要尽量保证 topic 数量不要过多，否则需要增加更多机器资源	千级，topic 达到千级时吞吐量会有较小幅度的下降。可以支撑大量 topic 是 RocketMQ 的一大优点	百万级	千级
消息 顺序性	分区有序	有序	有序	有序
消息 重复	至少一次，最多一次	至少一次，最多一次	至少一次	至少一次
事务	支持	支持	支持（对性能影响很大，一般不用）	activemq支持两种事务,本地事务,和分布式事务
时效性	ms级	ms级	微秒级，RabbitMQ的一大优点	ms级
可用性	非常高，分布式架构，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用	非常高，分布式架构	高，基于主从架构实现高可用性	高，基于主从架构实现高可用性
消息 可靠性	经过参数优化配置，理论上消息可以做到0丢失	经过参数优化配置，理论上消息可以做到0丢失	有较低的概率丢失数据	有较低的概率丢失数据
消息 回溯	支持（按offset回溯）	支持（按时间回溯）	不支持	不支持
功能 支持	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时流计算以及日志采集被大规模使用，是事实上的标准	MQ功能较为完善，还是分布式的，扩展性好	基于erlang开发，所以并发能力很强，性能极其好，延时很低	MQ领域的功能极其完备，activeMQ的一个优点
伸缩性	高伸缩性，每个主题（topic）包含多个分区（partition），主题中的分区可以分布在不同的主机（broker）中	高伸缩性，灵活的分布式横向扩展部署架构，整体架构和 kafka 很像	一般
管理 界面	普通	完善	普通	普通
持久化	消息可以持久化到磁盘	消息可以持久化到磁盘	持久化不好，可以持久化到内存、文件（对性能有影响）	可以持久化到内存、文件、数据库（对性能有影响）
消息 路由	不支持 不支持 支持
语言 支持	支持多语言，Java优先	支持Java、C++，但C++不成熟	支持几乎所有最受欢迎的编程语言：Java，C，C ++，C＃，Ruby，Perl，Python，PHP等	多语言支持，Java会更好一点
社区 活跃度	高	一般	高	高