常用的主流消息中间件介绍与性能对比(常用的主流消息中间件介绍与性能对比)
消息队列中间件是分布式系统中重要的组件,主要解决应用耦合、异步消息、流量削峰等问题。它可以实现高性能、高可用、可伸缩和最终一致性架构,是大型分布式系统不可缺少的中间件。
消息队列在电商系统、消息通讯、日志收集等应用中扮演着关键作用,作为提升应用性能的重要手段,分布式消息队列技术在互联网领域得到了越来越广泛的关注 。我们常用的分布式消息队列开源软件有:Kafka、ActiveMQ、RabbitMQ 及 RocketMQ。
消息队列是一种 “先进先出” 的数据结构;其中常运用的数据结构为链表(一般采用双向列表),其主要应用场景主要为3各方面:应用解耦、流量削锋、数据分发。
应用解耦:系统的耦合性越高,容错性就越低。以电商应用为例,用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出了故障或者因为升级等原因暂时不可用,都会造成下单操作异常,影响用户使用体验。
消息中间件应用解耦示意图
流量削锋:应用系统如果遇到系统请求流量的瞬间猛增,有可能会将系统压垮。有了消息队列可以将大量请求缓存起来,分散到很长一段时间处理,这样可以大大提到系统的稳定性和用户体验。
消息中间件流量削锋示意图
数据分发:通过消息队列可以让数据在多个系统之间进行流通。数据的产生方不需要关心谁来使用数据,只需要将数据发送到消息队列,数据使用方直接在消息队列中直接获取数据即可。
消息中间件数据分发示意图
ActiveMQ的优缺点ActiveMQ:是 Apache 出品,最流行的,能力强劲的开源消息总线,并且它一个完全支持 JMS 规范的消息中间件。
优点:
1. 基于 JAVA,跨平台运行
2. 可以用 JDBC 连接多种数据库
3. 有完善的界面、监控、安全机制
4. 自动重连和错误重试
缺点:
1. 社区活跃度不及 RabbitMQ
2. 目前重心放到 6.0 产品 Apollo,对 5 的 Bug 维护较少
3. 不适合用于上千个队列的应用场景
RibbitMQ的优缺点RibbitMQ:是使用 Erlang 语言开发的开源消息队列系统,基于 AMQP 协议来实现。
优点:
1. 基于 Erlang,支持高并发
2. 支持多种平台,多种客户端,文档齐全
3. 可靠性高
4. 在互联网公司有较大规模的应用,社区活跃度高
缺点:
1. Erlang语音较为小众,不利于二次开发
2. 代理架构下,中央节点增加了延迟,影响性能
3. 使用 AMQP 协议,使用起来有学习成本
RocketMQ的优缺点RocketMQ:是阿里开源的消息中间件,目前也已经孵化为 Apache 顶级项目,它是纯 Java 开发,具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。
优点:
1. 基于 Java,方便二次开发
2. 单机支持 1 万以上持久化队列
3. 内存与磁盘都有一份数据,保证性能 高可用
4. 开发度较活跃,版本更新很快
缺点:
1. 客户端种类不多,较成熟的是 Java、C 、GO等
2. RocketMQ 的官方文档相对简单一些
3. 社区关注度及成熟度不如 RabbitMQ
Kafka的优缺点Kafka:是 LinkedIn 开源的分布式发布-订阅消息系统,目前归属于 Apache 顶级项目。Kafka 主要特点是基于 Pull 的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输。
优点:
1. 原生的分布式系统
2. 零拷贝技术,减少IO操作步骤,提高系统吞吐量
3. 快速持久化:可以在O(1)的系统开销下进行消息持久化
4. 支持数据批量发送和拉取
缺点:
1. 单机超过64个队列/分区时,性能明显劣化
2. 使用短轮询方式,实时性取决于轮询间隔时间
3. 消费失败不支持重试
4. 可靠性比较差
消息中间件性能对比图
对比
ActiveMQ 最“老”,老牌,但维护较慢;
RabbitMQ 最“火”,各种场景通杀;
RocketMQ 最“猛”,功能强,但考验公司运维能力;
Kafka 最“强”,支持超大量数据,但消息可靠性弱。
结论:
中小型软件公司,建议选 RabbitMQ。一方面,erlang 语言天生具备高并发的特性,而且他的管理界面用起来十分方便。虽然RabbitMQ是开源的,但是国内能定制化开发erlang的程序员较少。所幸,RabbitMQ 的社区十分活跃,可以解决开发过程中遇到的bug,这点对于中小型公司来说十分重要。不考虑 rocketmq 和 kafka 的原因是,一方面中小型软件公司不如互联网公司,数据量没那么大,选消息中间件,应首选功能比较完备的,所以 kafka 排除。但是 rocketmq 已经交 apache管理,所以rocketmq 的未来发展趋势看好。
大型软件公司,根据具体使用在 rocketMq 和 kafka 之间二选一。一方面,大型软件公司,具备足够的资金搭建分布式环境,也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发,毕竟国内有能力改 JAVA 源码的人,还是相当多的。至于 kafka,根据业务场景选择,如果有日志采集功能,肯定是首选 kafka 了。具体该选哪个,看使用场景。
,免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com