最近要为公司的消息队列中间件进行选型,市面上相关的开源技术又非常多,如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
使用基于发布/订阅模式的消息传递机制,并支持多种消息路由机制,包括分区、复制和故障转移等。
总的来说,这三种
消息中间件
都具有不同的特点和适用场景,选择哪种
消息中间件
应该基于实际需求进行评估和选择。