最近要为公司的消息队列中间件进行选型,市面上相关的开源技术又非常多,如ActiveMQ、RabbitMQ、ZeroMQ、Kafka,还有阿里巴巴的RocketMQ等。

这么多技术,如何进行选型呢?

首先对于阿里的RocketMQ,因为是阿里开源的,对于国内开源的保持谨慎的态度,暂时不采取该中间件。

所以只能在ActiveMQ、RabbitMQ、ZeroMQ、Kafka中间选一款作为消息队列中间件。

下面从几个维度来对比下

1、社区活跃度

从目前网上的资料上看,RabbitMQ、activeMQ、ZeroMQ三者中RabbitMQ绝对是首选。

2、消息持久化

ZeroMq不支持消息持久化,ActiveMQ和RabbitMQ都支持。

3、核心技术

可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。

RabbitMq / Kafka最好,ActiveMQ次之,ZeroMQ最差。当然ZeroMQ也可以做到,不过自己必须手动写代码实现,工作量不小。尤其是可靠性中的:持久性、投递确认、发布者证实和高可用性。

4、高并发

毋庸置疑RabbitMQ最高,因为RabbitMQ是由天生具备高并发高可用特性的erlang语言实现的。

以上对比参考来源网络,大同小异。总结就是需要从RabbitMQ和Kafka之间选一款适合自己的。RabbitMQ和Kafka这两款无疑也是现在市场上有得比较多的两款消息队列中间件,从网络资料和面试要求也可以看得出来。

关于这两者非常全的评测,参考: http://geek.csdn.net/news/detail/246566

如何抉择??

总体来说,分布式消息中间件Kafka和RabbitMQ在行业认可、服务支持、可靠性、可维护性、兼容性、易用性等方面各有特色。Kafka在开源许可证、产品活跃度、性能、安全性、可扩展性等方面优于RabbitMQ,Kafka采用的许可证更宽松,活跃度更高,性能远高于RabbitMQ,在安全性和可扩展性方面能够提供更好的保障。Kafka仅在功能上略少于RabbitMQ,但是已经具备了主要的功能。

综合上述所有评测结果,我们决定选择Kafka。

干货: 2TB架构师四阶段视频教程

面经: 史上最全Java多线程面试题及答案

面经: 史上最全阿里高级Java面试题

面经: 史上最全Spring面试题

教程: 最全Spring Boot全套视频教程

书籍: 进阶Java架构师必看的15本书

工具: 推荐一款在线创作流程图、思维导图软件

分享Java干货,高并发编程,热门技术教程,微服务及分布式技术,架构设计,区块链技术,人工智能,大数据,Java面试题,以及前沿热门资讯等。

最近要为公司的消息队列中间件进行选型,市面上相关的开源技术又非常多,如ActiveMQ、RabbitMQ、ZeroMQ、Kafka,还有阿里巴巴的RocketMQ等。这么多技术,如何进行选型呢?首先对于阿里的RocketMQ,因为是阿里开源的,对于国内开源的保持谨慎的态度,暂时不采取该中间件。所以只能在ActiveMQ、RabbitMQ、ZeroMQ、Kafka中间选一款作为消息队列中
JMS即Java消息服务(Java Message Service)应用程序接口,是一个Java平台中关于面向 消息中间件 (MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。 消息中间件 一般都遵循JMS规范,如图: 消息队列 (Message Queue)也叫做 消息中间件 。生产者发送消息到 消息队列 ,消费者则从队列中获取消息进行消费,达到异步、解耦、削峰。 生产者发送消息有两种类型queue和topic。下载地址:https:// activemq .apache.org/compone
ZeroMQ : 扩展性好,开发比较灵活,采用C语言实现,实际上他只是一个socket库的重新封装,如果我们做为 消息队列 使用,需要开发大量的代码 RabbitMQ : 结合erlang语言本身的并发优势,性能较好,但是不利于做二次开发和维护 ActiveMQ : 历史悠久的开源项目,已经在
1. ActiveMq ,传统的 消息队列 ,使用Java语言编写。基于JMS(Java Message Service),采用多线程并发,资源消耗比较大。支持P2P和发布订阅两种模式。 2. RabbitMQ ,基于AMQP协议实现,支持多种场景,社区活跃量大。高性能,高可用,支持海量数据。 两者区别在于JMS和AMQP(此图取自别处), JMS提供了两种消息模型,peer-2-peer(点对点)以及...
1.什么是 消息中间件 举一个例子:假如我们都关注了亚洲航空的微信公众号,每当它发布新的优惠活动或者开通新的航线时,我们都可以收到这个公众号的通知,这就是一种广播订阅的模式。 公众号就是通过 消息中间件 来完成的 航空公司把编辑好的活动推送发给微信 消息中间件 的服务器,然后关注了这个公众号的粉丝手机上的微信 消息中间件 的客户端,就会自动去把消息获取出来显示。 2.目前的 消息中间件 有很多种,最常用的就是Act...
ActiveMQ RabbitMQ Kafka 都是 消息队列 (Message Queue)系统。 ActiveMQ 是一个开源的、基于Java的 消息队列 系统,支持多种通信协议,如AMQP、STOMP、MQTT等,可以用于异步通信、解耦、负载均衡等场景。 RabbitMQ 也是一个开源的、基于Erlang语言的 消息队列 系统,支持AMQP协议,具有高可用性、可靠性和可扩展性,适用于分布式系统、微服务架构等场景。 Kafka 是一个分布式的、基于Scala语言的 消息队列 系统,主要用于大规模数据处理和分析,支持高吞吐量、低延迟、可靠性等特性,适用于流处理、日志收集、实时分析等场景。 ### 回答2: ActiveMQ RabbitMQ Kafka 都是流行的 消息队列 系统,它们都可以用于实现消息传递、解耦合和异步通信等场景。但是,它们之间在设计理念、使用场景和架构模型等方面存在不同。 ActiveMQ 是一个基于 JMS(Java Message Service)标准的 消息中间件 ,使用开源的 Apache ActiveMQ 作为消息服务提供商。它提供了多种传输协议和消息协议(如 AMQP、MQTT 和 STOMP 等),支持广泛的编程语言和平台。 ActiveMQ 提供了完整的 JMS 消息模型,包括点对点和发布-订阅模式,并提供了事务和持久化等高级功能。 ActiveMQ 是一个比较成熟和稳定的消息系统,适合于大规模企业级应用,但是在高并发场景下,可靠性和性能可能会受到影响。 RabbitMQ 是一个使用 Erlang 语言编写的 AMQP (Advanced Message Queuing Protocol) 消息中间件 ,其架构采用分布式节点的方式,能够实现高可用和高可靠性。 RabbitMQ 支持多种消息协议,并提供了丰富的插件和 API,支持多种编程语言。 RabbitMQ 支持点对点和发布-订阅模式,提供了事务和持久化等高级功能,支持复杂的路由策略和负载均衡。 RabbitMQ 的设计哲学是“居于中间,支持多个端点”,即将中间件作为独立的透明服务器,将业务系统与消息的传输和处理相分离,从而实现解耦合和高度灵活性。 Kafka 是一个分布式的、高吞吐量的 消息中间件 ,其特点是支持高并发和高可靠性,主要用于实时流数据的处理和分发。 Kafka 的设计思想是“纯日志”,即将消息作为日志进行处理,其架构采用“发布-订阅”模式,支持多个消费者消费同一份消息。 Kafka 支持水平扩展,可以通过增加分区和副本来提高性能和可用性,同时还提供了消息缓存和消息存储等高级功能。 Kafka 适合于处理大规模数据流和业务处理,但是其功能相对较简单,对开发人员要求较高。 综上所述, ActiveMQ RabbitMQ Kafka 都具有各自独特的优势和适用场景。选择一个 消息队列 系统时,需要根据具体的业务需求和性能要求进行考虑,在可靠性、性能、灵活性和易用性等方面进行综合评估和比较。同时,也需要注意消息协议的兼容性和编程语言的支持等因素。 ### 回答3: Activemq Rabbitmq Kafka 都是 消息中间件 ,用于实现分布式系统中不同组件之间的消息传递。 Activemq 是基于Java的开源 消息中间件 ,它使用JMS(Java Messaging Service)API来实现消息传递,支持多种传输协议,例如TCP、SSL、NIO以及JMS等。 Activemq 具有高度可靠性和可伸缩性以及易于管理的特点,可以支持多种消息模型,包括点对点、发布/订阅和持久订阅。 与 Activemq 相比, Rabbitmq 是一个更轻量级的开源消息代理,由Erlang编写,使用AMQP(Advanced Message Queuing Protocol)进行消息传递。它提供了多种消息路由机制,包括直接、主题和分发,可以灵活地处理不同类型的消息传递场景。此外, Rabbitmq 还具有高度可靠性、可扩展性和易于管理的特点。 与 Activemq Rabbitmq 相比, Kafka 则更适合大数据处理环境。 Kafka 是一个分布式的流式平台,可以快速处理海量数据,通过分布式的存储和处理机制,使得数据具有高可靠性和高性能,可以应对海量数据的实时处理。 Kafka 使用基于发布/订阅模式的消息传递机制,并支持多种消息路由机制,包括分区、复制和故障转移等。 总的来说,这三种 消息中间件 都具有不同的特点和适用场景,选择哪种 消息中间件 应该基于实际需求进行评估和选择。