消息队列——ActiveMQ、RocketMQ、RabbitMQ、Kafka区别性能比较


一、消息简介

“消息”是在两台计算机间传送的数据单位。消息可以非常简单,例如只包含文本字符串;也可以更复杂,可能包含嵌入对象。
消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。
队列的主要目的是提供路由并保证消息的传递;如果发送消息时接收者不可用,消息队列会保留消息,直到可以成功地传递它。

二、为什么要使用消息队列(优点)

1.解耦

传统系统对接过程即新的系统的接入会对新系统进行代码层面的调整。
引入消息队列则不再需要更改原系统,直接根据业务情况进行消息的订阅即可。
系统之间的耦合性大大降低。

2.异步

传统的业务处理上非必要的业务逻辑也只能一个个去处理。整个流程下来需要很长时间。
引入消息队列则可以将消息写入消息队列,非必要的业务逻辑以异步的方式运行,加快响应速度

3.削峰

传统系统并发量大的时候直接对接数据库导致数据库连接异常。
引入消息队列则可以按照数据库能处理的并发量,从消息队列中慢慢拉取消息。在生产中,这个短暂的高峰期积压是允许的。

三、消息队列所带来的问题(缺点)

3.1 系统可用性降低

消息中间件引入后出现宕机等问题就会导致当前系统的不可用。
当然解决办法可以使用集群高可用的方式,但是这样也会带来其他问题即系统的复杂性的增加。

3.2 系统复杂性增加

系统复杂性需要去考虑很多方面的问题,比如
如何保证消息不被重复消费,
如何保证保证消息可靠传输。
如果使用分布式事务还要考虑数据最终消费的一致性问题。

四、消息队列的选型

4.1 性能对比表

特性ActiveMqRabbitMQRocketMQKafka
开发语言javaerlangjavascala
单机吞吐量万级万级10万级10万级
时效性ms级us级ms级ms级
可用性高(主从架构)高(主从架构)非常高(分布式架构)非常高(分布式架构)
功能特性成熟的产品,在很多公司得到应用;有较多的文档;各种协议支持较好基于erlang开发,所以并发能力很强,性能极其好,延时很低;管理界面较丰富MQ功能比较完备,扩展性佳只支持主要的MQ功能,像一些消息查询,消息回溯等功能没有提供,毕竟是为大数据准备的,在大数据领域应用广。

综合上面的材料得出以下两点:

(1)中小型软件公司,建议选RabbitMQ.一方面,erlang语言天生具备高并发的特性,而且他的管理界面用起来十分方便。
正所谓,成也萧何,败也萧何!他的弊端也在这里,虽然RabbitMQ是开源的,然而国内有几个能定制化开发erlang的程序员呢?
所幸,RabbitMQ的社区十分活跃,可以解决开发过程中遇到的bug,这点对于中小型公司来说十分重要。
`不考虑rocketmq和kafka的原因`:
一方面中小型软件公司不如互联网公司,数据量没那么大,选消息中间件,应首选功能比较完备的,所以kafka排除。
`不考虑rocketmq的原因`:
rocketmq是阿里出品,如果阿里放弃维护rocketmq,中小型公司一般抽不出人来进行rocketmq的定制化开发,因此不推荐。

(2)大型软件公司,根据具体使用在rocketMq和kafka之间二选一。
一方面,大型软件公司,具备足够的资金搭建分布式环境,也具备足够大的数据量。
针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发,毕竟国内有能力改JAVA源码的人,还是相当多的。
至于kafka,根据业务场景选择,如果有日志采集功能,肯定是首选kafka了。具体该选哪个,看使用场景。

参考文章:

https://www.cnblogs.com/xiapu5150/p/9927323.html

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值