MQ之kafaka、RocketMQ、RabbitMQ对比

发表评论
346 views

A+

所属分类：Java

好奇新

于 2021-11-29 10:43:53 发布

120

分类专栏： Tools 文章标签：中间件 java rabbitmq

版权

Tools

专栏收录该内容

18 篇文章0 订阅

订阅专栏

MQ之主流MQ：kafaka、RocketMQ、RabbitMQ对比

应用场景

优缺点

优点

缺点

产品对比

主流协议扩展

MQ笔记

MQ之主流MQkafaka+RocketMQ+RabbitMQ对比：https://blog.csdn.net/weixin_42526326/article/details/121604583

MQ之RocketMQ常见错误：https://blog.csdn.net/weixin_42526326/article/details/121578747

MQ之RocketMQ专业术语：https://blog.csdn.net/weixin_42526326/article/details/121578780

MQ之RocketMQ环境详细配置：https://blog.csdn.net/weixin_42526326/article/details/121522113

应用场景

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。

异步通信

有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

解耦

降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

冗余

有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

扩展性

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。

过载保护

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

可恢复性

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

顺序保证

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。

缓冲

在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。

数据流处理

分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。

优缺点

优点

系统解耦

交互系统之间没有直接的调用关系，只是通过消息传输，故系统侵入性不强，耦合度低。

提高系统响应时间

例如原来的一套逻辑，完成支付可能涉及先修改订单状态、计算会员积分、通知物流配送几个逻辑才能完成；通过MQ架构设计，就可将紧急重要（需要立刻响应）的业务放到该调用方法中，响应要求不高的使用消息队列，放到MQ队列中，供消费者处理。

为大数据处理架构提供服务

通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持。

Java消息服务——JMS

Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。

JMS中的P2P和Pub/Sub消息模式：点对点（point to point， queue）与发布订阅（publish/subscribe，topic）最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)。

缺点

项目的复杂度提高

MQ的高度依赖

产品对比

特性 ActiveMQ RabbitMQ RoketMQ Kafka

资料文档多多少多

开发语言 JAVA Erlang JAVA Scala

支持协议 OpenWire、STOMP、

REST、XMMP、AMQP AMQP 自定义自定义（基于TCP）

持久化内存、磁盘、数据库；

支持大量堆积内存、磁盘；

支持少量堆积磁盘；

支持大量堆积内存、磁盘、数据库；

支持大量堆积

可用性高（主从）高（主从）非常高(分布式) 非常高(分布式)

订阅方式点对点（p2p）、广播（发布订阅） direct、topic、Headers、fanout 正则匹配的发布订阅广播（发布订阅）

消息丢失低低理论不丢失理论不丢失

消息重试不支持不支持，但是可以用消息确认机制实现支持不支持，可以通过其他方式实现

消息重复支持at least once 支持at least once、at most once 支持at least once 支持at least once、at most once

消息延迟QPS 毫秒级微秒级毫秒级毫秒级

单机吞吐量TPS 万级万级万级十万级

社区活跃度高高中高

事务支持支持支持

负载均衡支持支持（不友好）支持支持

并发度高极高高高

评价成熟的产品，已经在很多的公司得到应用，有成熟的客户端；

不够稳定，会出现消息丢失的情况，社区不够活跃 erlang语言，性能很好，管理界面丰富；

Erlang语言门槛较高，集群不支持动态部署综合性能

产品新文档比较缺乏性能很强，安全性不够高，多用于分布式日志 ELK Stack 和大数据领域

主流协议扩展

AMQP协议

AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。

优点：可靠、通用

MQTT协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。

优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

STOMP协议

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。

优点：命令模式（非topic\queue模式）

XMPP协议

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。

优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

其他基于TCP/IP自定义的协议

有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。

参考：

https://blog.csdn.net/wqc19920906/article/details/82193316

————————————————

原文链接：https://blog.csdn.net/weixin_42526326/article/details/121604583