消息队列优缺点及各种MQ对比

Posted qmillet

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了消息队列优缺点及各种MQ对比相关的知识,希望对你有一定的参考价值。

一、消息队列使用场景

1. 异步处理

  传统业务并行处理:

技术图片

   消息队列进行处理:

技术图片

 2. 应用解耦

  传统业务调用,耦合性太高。

技术图片

 

 

   采用消息队列进行处理, 降低耦合性。技术图片

 3. 流量削峰

  每天0点到11点,A系统风平浪静,每秒并发请求数量就100个。结果每次一到11点~1点,每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求啊,导致系统崩溃。

技术图片

技术图片

 

 4. 消息通讯

  消息通讯是指,消息队列一般都内置了高效的通信机制,因此也可以用在纯的消息通讯。比如实现点对点消息队列,或者聊天室等。

技术图片

 

 技术图片

 

5. 日志处理

   日志处理是指将消息队列用在日志处理中,比如Kafka的应用,解决大量日志传输的问题。架构简化如下

技术图片

 

 

二、消息队列缺点

技术图片

  系统可用性降低:系统引入的外部依赖越多,越容易挂掉,本来你就是A系统调用BCD三个系统的接口就好了,人ABCD四个系统好好的,没啥问题,你偏加个MQ进来,万一MQ挂了咋整?MQ挂了,整套系统崩溃了,你不就完了么。

  系统复杂性提高:硬生生加个MQ进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已

  一致性问题:A系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是BCD三个系统那里,BD两个系统写库成功了,结果C系统写库失败了,咋整?你这数据就不一致了。

 

二、RobbitMQ、RocketMQ、Kafak对比

特性

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唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略

 

这个特性天然适合大数据实时计算以及日志收集

   总结:

     RabbitMQ:性能好,延时低,管理界面好用,社区活跃。但是吞吐量比较低,erlang语言实现,不好进行进一步开发扩展。

     RocketMQ:接口简单易用,源码是阿里出品,可自定义MQ。但是社区活跃度一般,万一不维护,需要自己公司研发。

     Kafka:仅仅提供较少的核心功能,但是具备超高的吞吐量和ms级的延迟,极高的可用性和拓展性。但是存在消息重复消费的缺点,适合于大数据实时计算和日志收集。

 

以上是关于消息队列优缺点及各种MQ对比的主要内容,如果未能解决你的问题,请参考以下文章

消息队列篇—常用消息队列MQ产品介绍及对比

超详细消息队列MQ使用时常见问题以及解决办法

消息队列(MQ)消息延迟及过滤设计方案

MQ消息队列及常见MQ比较

消息队列的使用场景及优缺点?

MQ定义/优缺点/几种MQ对比