RabbitMQ有什么优缺点

文章讨论了不同消息中间件的优缺点,如RabbitMQ的高并发、高吞吐和管理界面,但基于Erlang的源码不易定制;RocketMQ适合大规模高并发场景,且支持分布式事务,但社区活跃度不高;Kafka适用于大数据实时处理,而ActiveMQ在互联网公司应用较少。建议中小型企业使用RabbitMQ,大型或技术实力强的公司考虑RocketMQ,大数据实时计算场景推荐Kafka。
摘要由CSDN通过智能技术生成

RabbitMQ有什么优缺点?A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是, 要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了, 咋整?你这数据就

不一致了。

所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对 它带来的坏处做各种额外的技术方案和架构来规避掉,做好之后,你会发现,妈 呀,系统复杂度

提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用, 还是得用的。

这个首先你可以说下你们公司选用的是什么消息中间件,比如用的是 RabbitMQ,然后可以初步给一些你对不同MQ中间件技术的选型分析。

举个例子:比如说ActiveMQ是老牌的消息中间件,国内很多公司过去运用的还 是非常广泛的,功能很强大。

但是问题在于没法确认ActiveMQ可以支撑互联网公司的高并发、高负载以及高 吞吐的复杂场景,在国内互联网公司落地较少。而且使用较多的是一些传统企 业,用ActiveMQ

异步调用和系统解耦。

然后你可以说说RabbitMQ,他的好处在于可以支撑高并发、高吞吐、性能很 高,同时有非常完善便捷的后台管理界面可以使用。

另外,他还支持集群化、高可用部署架构、消息高可靠支持,功能较为完善。

而且经过调研,国内各大互联网公司落地大规模RabbitMQ集群支撑自身业务的 case较多,国内各种中小型互联网公司使用RabbitMQ的实践也比较多。

除此之外,RabbitMQ的开源社区很活跃,较高频率的迭代版本,来修复发现的 bug以及进行各种优化,因此综合考虑过后,公司采取了RabbitMQ

但是RabbitMQ也有一点缺陷,就是他自身是基于erlang语言开发的,所以导致 较为难以分析里面的源码,也较难进行深层次的源码定制和改造,毕竟需要较为 扎实的erlang

言功底才可以。

然后可以聊聊RocketMQ,是阿里开源的,经过阿里的生产环境的超高并发、 高吞吐的考验,性能卓越,同时还支持分布式事务等特殊场景。

而且RocketMQ是基于Java语言开发的,适合深入阅读源码,有需要可以站在 源码层面解决线上生产问题,包括源码的二次开发和改造。

另外就是KafkaKafka提供的消息中间件的功能明显较少一些,相对上述几款 MQ中间件要少很多。

但是Kafka的优势在于专为超高吞吐量的实时日志采集、实时数据同步、实时数 据计算等场景来设计。

因此Kafka在大数据领域中配合实时计算技术(比如Spark Streaming StormFlink)使用的较多。但是在传统的MQ中间件使用场景中较少采用。

ActiveMQ

RabbitMQ

RocketMQ

Kafka

ZeroMQ

单机吞吐

 RabbitM Q

2.6w/s

消息做持 久化)

11.6w/s

17.3w/s

29w/s

开发语言

Java

Erlang

Java

Scala/Java

C

主要维护

Apache

Mozilla/Spring

Alibaba

Apache

iMatix

始人已去

成熟度

成熟

成熟

开源版本不够成熟

比较成熟

只有C

PHP等版

本成熟

订阅形式

点对点 (p2p)、广 播(发布

订阅)

提供了4 种: direct,

topic,Headers  fanout

fanout就 是广播模 式

基于 topic/me ssageTag 以及按照消

息类 型、属性 进行正则 匹配的发 布

订阅模 式

基于topic 以及按照 topic进行

正则匹配的发布订 阅模式

点对点

(P2P)

持久化

支持少量 堆积

支持少量 堆积

支持大量 堆积

支持大量 堆积

不支持

顺序消息

不支持

不支持

支持

支持

不支持

性能稳定

一般

较差

很好

集群方式

支持简单 集群模 式,比

主备,对 高级集群 模式

支持 不好。

支持简单 集群,'复 制模 式,

对高 级集群模 式支持不 好。

常用 多 对’Mast erSlave’ 模 式,开源

版本需手 动切换 Slave变成 Master

天然 的‘Lead erSlave’无 状态集

群,每台 服务器既 是Master

也是Slave

不支持

管理界面

一般

较好

一般

综上,各种对比之后,有如下建议:

一般的业务系统要引入 MQ,最早大家都用 ActiveMQ,但是现在确实大家用 的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是 算了吧,我个人不

推荐用这个了;

后来大家开始用 RabbitMQ,但是确实 erlang 语言阻止了大量的 Java 工程师 去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开 源的,比较稳定的

支持,活跃度也高;

不过现在确实越来越多的公司会去用 RocketMQ,确实很不错,毕竟是阿里出 品,但社区可能有突然黄掉的风险(目前 RocketMQ 已捐给 Apache,但 GitHub 上的活跃度其实

不算高)对自己公司技术实力有绝对自信的,推荐用 RocketMQ,否则回去老老实实用 RabbitMQ 吧,人家有活跃的开源社区,绝 对不会黄。

所以中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是 不错的选择;大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选 择。

如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝 对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性 规范。

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

知一NN

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值