消息队列面试突击系列--消息产品对比
表格对比
|
特性 |
ActiveMQ |
RabbitMQ |
RocketMQ |
Kafka |
|
单机吞吐量 |
万级，吞吐量比RocketMQ和Kafka要低了一个数量级 |
万级，吞吐量比RocketMQ和Kafka要低了一个数量级 |
10万级，RocketMQ也是可以支撑高吞吐的一种MQ |
10万级别，这是kafka最大的优点，就是吞吐量高。
一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
|
topic数量对吞吐量的影响 |
|
|
topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降
这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic |
topic从几十个到几百个的时候，吞吐量会大幅度下降
所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源 |
|
时效性 |
ms级 |
微秒级，这是rabbitmq的一大特点，延迟是最低的 |
ms级 |
延迟在ms级以内 |
|
可用性 |
高，基于主从架构实现高可用性 |
高，基于主从架构实现高可用性 |
非常高，分布式架构 |
非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
|
消息可靠性 |
有较低的概率丢失数据 |
|
经过参数优化配置，可以做到0丢失 |
经过参数优化配置，消息可以做到0丢失 |
|
功能支持 |
MQ领域的功能极其完备 |
基于erlang开发，所以并发能力很强，性能极其好，延时很低 |
MQ功能较为完善，还是分布式的，扩展性好 |
功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准 |
|
优劣势总结 |
非常成熟，功能强大，在业内大量的公司以及项目中都有应用
偶尔会有较低概率丢失消息
而且现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本
而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用
|
erlang语言开发，性能极其好，延时很低；
吞吐量到万级，MQ功能比较完备
而且开源提供的管理界面非常棒，用起来很好用
社区相对比较活跃，几乎每个月都发布几个版本分
在国内一些互联网公司近几年用rabbitmq也比较多一些
但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。
而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。
而且rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。 |
接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障
日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景
而且一个很大的优势在于，阿里出品都是java系的，我们可以自己阅读源码，定制自己公司的MQ，可以掌控
社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码
还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的 |
kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展
同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量
而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略
这个特性天然适合大数据实时计算以及日志收集 |
描述对比
1. RabbitMQ
简介：老牌儿消息队列 RabbitMQ，俗称兔子 MQ
编程语言：Erlang
特点：轻量级、迅捷，“开箱即用的消息队列”，非常容易部署和使用
区别点：
1、它在生产者（Producer）和队列（Queue）之间增加了一个 Exchange 模块，你可以理解为交换机。这个 Exchange 模块的作用和交换机也非常相似，根据配置的路由规则将生产者发出的消息分发到不同的队列中。路由的规则也非常灵活，甚至你可以自己来实现路由规则。
2、支持编程语言最多
缺点：
1、RabbitMQ 对消息堆积的支持并不好，在它的设计理念里面，消息队列是一个管道，大量的消息积压是一种不正常的情况，应当尽量去避免。当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降
2、RabbitMQ 的性能是我们介绍的这几个消息队列中最差的，根据官方及日常经验测试数据，依据硬件配置的不同，它大概每秒钟可以处理几万到十几万条消息。可满足绝大多数场景，若有特别高要求不建议。
3、Erlang语言偏小众且学习曲线非常陡峭。
2. RocketMQ
简介：阿里巴巴在 2012 年开源的消息队列产品，后来捐赠给 Apache 软件基金会，2017 正式毕业，成为 Apache 的顶级项目。经历过多次“双十一”考验，它的性能、稳定性和可靠性都是值得信赖的
开发语言：java
特点：无突出特点及缺点，有着不错的性能，稳定性和可靠性，具备一个现代的消息队列应该有的几乎全部功能和特性，中文社区活跃
区别点：RocketMQ 对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，性能比 RabbitMQ 要高一个数量级，每秒钟大概能处理几十万条消息
缺点：作为国产的消息队列，相比国外的比较流行的同类产品，在国际上还没有那么流行，与周边生态系统的集成和兼容程度要略逊一筹。
3. Kafka
简介：最早是由 LinkedIn 开发，目前也是 Apache 的顶级项目。Kafka 最初的设计目的是用于处理海量的日志。早期为优化性能设计上牺牲，比如不保证消息可靠性，可能会丢失消息，不支持集群，功能简陋。随后的几年 Kafka 逐步补齐了这些短板，Kafka 已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求。
开发语言：java和Scala
特点：设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。Kafka 的性能，尤其是异步收发的性能，是三者中最好的，但与 RocketMQ 并没有量级上的差异，大约每秒钟可以处理几十万条消息。极限处理能力可以超过每秒 2000 万条消息。
区别点：
1、周边支持好，几乎所有的相关开源系统软件都会优先支持Kafka
2、性能高
缺点： Kafka 这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送，在它的 Broker 中，很多地方都会使用这种“先攒一波再一起处理”的设计。当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。
二梯队消息队列
ActiveMQ
最老牌的开源消息队列，是十年前唯一可供选择的开源消息队列，目前已进入老年期，社区不活跃。无论是功能还是性能方面，ActiveMQ 都与现代的消息队列存在明显的差距，它存在的意义仅限于兼容那些还在用的爷爷辈儿的系统。
ZeroMQ
严格来说 ZeroMQ 并不能称之为一个消息队列，而是一个基于消息队列的多线程网络库，如果你的需求是将消息队列的功能集成到你的系统进程中，可以考虑使用 ZeroMQ。
Pulsar
很多人可能都没听说过这个产品，Pulsar 是一个新兴的开源消息队列产品，现为apache孵化项目，最早是由 Yahoo 开发，目前处于成长期，流行度和成熟度相对没有那么高。与其他消息队列最大的不同是，Pulsar 采用存储和计算分离的设计，我个人非常喜欢这种设计，它有可能会引领未来消息队列的一个发展方向，建议你持续关注这个项目。
小惊喜
1、积少成多，下载高佣联盟，领取各大平台隐藏优惠券，每次购物省个十块八块不香吗，通过下方二维码注册的用户可添加微信liershuang123（微信号）领取价值千元海量学习视频。
为表诚意奉献部分资料：
软件电子书：链接：https://pan.baidu.com/s/1_cUtPtZZbtYTF7C_jwtxwQ 提取码：8ayn
架构师二期：链接：https://pan.baidu.com/s/1yMhDFVeGpTO8KTuRRL4ZsA 提取码：ui5v
架构师阶段课程：链接：https://pan.baidu.com/s/16xf1qVhoxQJVT_jL73gc3A 提取码：2k6j
2、本人重金购买付费前后端分离脚手架源码一套，现10元出售，加微信liershuang123获取源码
