RabbitMQ 与 Memphis.dev哪个好？主流消息队列框架差异对比

消息队列组件目前已经成为构建项目的重要组成部分，其主要就是提供正确的路由来保证消息的传递，并且可以实现异步传输以及信息存储的功能。目前流行的消息队列插件就是RabbitMQ，而下一代的消息队列协议以Memphis.dev最为流行。今天icode9小编就详细讲解下这俩个消息队列协议的区别。以便各位编程人员更为方便的选择。
 

什么是 RabbitMQ？

RabbitMQ 是一种轻量级且易于部署的消息队列，适用于本地和云环境。它支持多种消息传递协议。RabbitMQ可以部署在分布式和联合配置中，以满足大规模、高可用性的要求。

什么是 Memphis.dev？

Memphis是下一代消息代理。

一个简单、健壮、持久的云原生消息代理，包裹着一个完整的生态系统，可以快速可靠地开发下一代事件驱动的用例。

Memphis.dev 支持构建下一代应用程序，这些应用程序需要大量流式传输和丰富的数据、现代协议、零操作、快速开发、极大的成本降低以及面向数据的开发人员和数据工程师的开发时间显着减少。

---

一般的

范围	MEMPHIS.DEV	兔MQ
执照	阿帕奇 2.0	Mozilla 公众号
组件	Memphis + MongoDB（正在删除 MDB）	兔MQ
消息消费模型	拉	推
存储架构	日志	指数

执照

这两种技术都可以在完全开源许可下使用。Memphis 还有一个基于商业的发行版，增加了安全性、分层存储等。

组件

Memphis 使用 MongoDB 仅用于 GUI 状态管理，并将很快被删除，使 Memphis 没有任何外部依赖。Memphis 和 RabbitMQ 都是使用 RAFT 达成共识。

消息消费模型

RabbitMQ 使用与传统消息系统同义的基于推送的方法。

Memphis 使用基于拉取的架构，其中消费者从服务器拉取消息，长轮询确保新消息即时可用。

基于拉的架构通常更适合高吞吐量的工作负载，因为它们允许消费者管理他们的流量控制，只获取他们需要的东西。

存储架构

RabbitMQ 使用基于索引的存储系统。它们将数据保存在树结构中，以提供确认单个消息所需的快速访问。

Memphis 使用称为 streams（由 NATS Jetstream 制作）的分布式提交日志作为其存储层，可以将其完全写入代理（服务器）的内存或磁盘上。此外，Memphis 默认抽象偏移量，因此保存已使用偏移量的记录驻留在 Memphis 而不是客户端。

讯息

范围	MEMPHIS.DEV	兔MQ
表现	每个站（队列）每秒 300K 条消息。	每秒 4K-10K 条消息
消息保留	基于策略（例如，30 天）	基于确认
数据类型	事务性、操作性	事务性的
消费者模式	智能经纪人/智能消费者	聪明的经纪人/愚蠢的消费者
拓扑结构	基于发布/订阅	交换类型：直接、扇出、主题、基于标头
有效载荷大小	高达15M	没有限制
用例	海量数据/高通量案例 | 简单用例	简单用例
交期保证	至少一次，恰好一次	特别是对于使用单个队列的事务，它不保证原子性。
消息排序	消息排序是通过消费者组提供的。通过消息键，消息被发送到站。	不受支持。
消息优先级	不可用	您可以在 RabbitMQ 中设置消息优先级，并按照优先级最高的顺序消费消息。
消息生命周期	由于站消息保存在文件/内存中。这可以通过定义保留策略来控制。	因为RabbitMQ是一个队列，消息被读取后就被丢弃，并给出一个确认。
聚类	双活	主动-被动
多区域	支持的*	不
多租户	命名空间包括节点选择*	主机
只读副本	支持的*	不
跨节点数据条带化	支持的	不

*适用于孟菲斯云用户。

数据流

RabbitMQ 使用独特的、有界的数据流。消息由生产者创建和发送，并由消费者接收。Memphis 使用无限数据流，键值对不断流向指定的站点。

数据使用

RabbitMQ 最适合交易数据，例如订单形成、放置和用户请求。Memphis 非常适合处理事务和操作数据，例如流程操作、审计和日志统计以及系统活动。

消息保留

RabbitMQ 将消息推送给消费者。这些消息在处理和确认后将从队列中删除。孟菲斯是一个日志。它使用连续的消息，这些消息留在站（队列）中直到保留期到期。

拓扑结构

RabbitMQ 使用交换队列拓扑——将消息发送到一个交换器，在那里它们又被路由到各种队列绑定以供消费者使用。Memphis 使用发布/订阅拓扑，通过流将消息发送到正确的站点，然后由不同授权组中的用户使用。

架构差异

在 Memphis 和 RabbitMQ 之间进行选择时，内部操作和基本设计可能是必不可少的考虑因素。

RabbitMQ 架构的组件包括以下内容：

• 队列：它负责跟踪已收到的消息，并且可能具有指定它可以对消息执行的操作的配置数据。
• 交换： 交换接收发送到 RabbitMQ 的消息，并确定它们应该转发到哪里。交换定义用于消息的路由策略，最常见的是检查与消息一起传输或包含在其属性中的数据特征。
• 生产者： 生产消息并将它们发送到代理服务器（发布）。有效负载和标签是消息的两个组成部分。用户想要传送的数据是有效载荷。该标签指定谁应该接收消息的副本并描述有效负载。
• 消费者：它订阅队列并连接到代理服务器。
• 经纪人： 应用程序可以通过经纪人相互交换信息和通信。
• 绑定：它告诉交换器哪些队列可以分发消息。此外，绑定将指示交换过滤允许将哪些消息添加到特定交换类型的队列中。

孟菲斯架构使用以下组件设计：

• 副本： Memphis 最重要的元素之一是复制，它确保即使代理遇到问题也能发布和使用消息。
• RAFT：它维护代理之间的数据协调，例如配置、位置、数据和状态详细信息。
• 生产者：生产者将消息推送或发布到在孟菲斯经纪人上创建的孟菲斯站。生产者还可以同步或异步地向代理发送消息。
• 消费者：订阅孟菲斯站并从中提取消息的个人。Memphis 允许将数据存储在除内部磁盘和内存之外的附加存储平台中，供联机事务处理 (OLTP) 程序使用。
• Broker：充当 Memphis 服务器或代理。每个消息的流数是根据代理存储消息的顺序定义的。

可扩展性和冗余

RabbitMQ 使用循环队列来重复消息。消息在队列之间分配以提高吞吐量和平衡负载。此外，它使众多消费者能够同时读取来自不同队列的消息。

在 Memphis 中，可伸缩性和冗余由流对象提供。该流在众多经纪人之间重复。如果其中一个代理发生故障，数据仍然可以由另一个代理提供服务。

如果数据只存储在一个代理中，那么对该代理的依赖就会增加，这是危险的，并且会增加失败的可能性。此外，分发流将大大提高吞吐量。

多区域/多云

RabbitMQ 中最高的可用性能力是集群和仲裁队列，它们支持跨节点复制。

除了跨多个代理的镜像和条带化站外，最终还可以跨越可用区。合作伙伴和孟菲斯云用户可以在主动/被动拓扑中跨区域建立孟菲斯超级集群。

多租户

RabbitMQ是一个多租户系统：连接、交换、队列、绑定、用户权限、策略和其他一些东西属于虚拟主机和实体的逻辑组。

Memphis 支持使用命名空间的多租户，它提供了与连接、生产者、消费者、安全、专用仪表板（包括节点选择）的完全分离。

 

队列条带化

操作 RabbitMQ 代理所需的所有数据/状态都在所有节点之间复制。一个例外是消息队列，它默认驻留在一个节点上，尽管它们对所有节点都是可见的和可访问的。要跨集群中的节点复制队列，请使用支持复制的队列类型。Quorum Queues指南中涵盖了该主题。

Memphis 根据定义的策略（副本）跨代理复制数据。孟菲斯站还可以跨越和条带化跨代理的数据，以实现更高的吞吐量和可用性。

特征

范围	MEMPHIS.DEV	兔MQ
GUI	是的	是的
模式管理	是的	不
通配符消费	不	是的
流丰富	是的	不
即用型源/汇连接器	是的	不
流血统	是的	不
数据级可观察性	是的	是的
自愈	是的	不
去重	是的。修改后的布隆过滤器	是的
死信	是的	是的
休息网关	是的	不
消费者内部沟通	实验性的	不
生产部署环境	库伯内斯	Kubernetes、裸机
存储分层	用于归档的磁盘、内存和 S3	磁盘、内存
通知	Slack、电子邮件等	使用名为 Alertmanager 的外部项目
SDK支持	节点 js、Python、Go、.NET、Java、NestJS 和 Typescript	Python、Ruby、Elixir、PHP、Swift、Go、Java、C、Spring、.Net 和 JavaScript

 

GUI

RabbitMQ 提供了一个本机 GUI，它也可以充当管理层。

Memphis 提供了托管在代理内部的最先进的本机 GUI，构建为充当所有 Memphis 方面的管理层，包括集群配置、资源、数据可观察性、通知、处理等。 

 

模式管理

控制和确保在不同所有者之间流经您的组织的数据质量的最基本构建块是定义编写良好的模式和数据模型。模式管理的好处是允许分离的客户端之间的兼容性。

作为其开源版本的一部分，Memphis 展示了 Schemaverse，它也嵌入在代理中。Schemaverse 在 Memphis 代理之上提供了一个强大的模式存储和模式管理层，无需独立的计算或专用资源。通过独特的现代 UI 和编程方法，技术和非技术用户可以创建和定义不同的模式，将模式附加到多个站点，并选择是否应强制执行该模式。此外，与 Schema Registry 相反，客户端不需要实现序列化功能，并且每次模式更新都发生在生产者运行时。

通配符消费

使用单个连接使用来自多个队列的消息的能力。

在 RabbitMQ 中，消息不会直接发布到队列中。相反，生产者将消息发送到交换器。交换器是由 RabbitMQ 中的虚拟主机定义的消息路由代理。交换器负责在标头属性、绑定和路由键的帮助下将消息路由到不同的队列。

孟菲斯目前不支持它。

流丰富

使用无服务器函数或 SQL 语句修饰生成的消息的能力。

RabbitMQ 不支持它。

Memphis 提供了与 Kafka 流等类似的行为。嵌入在代理中，Memphis 用户可以创建无服务器类型的功能或完整的容器化应用程序，聚合多个站点和流，装饰和丰富来自不同来源的消息，编写无法通过 SQL 实现的复杂功能，并操纵模式。此外，Memphis 嵌入式连接器框架将有助于将结果直接推送到定义的接收器。

即用型源/汇连接器

Memphis 提供与 NATS 协议兼容的集成、基于 Memphis 的集成和即用型连接器，这些连接器可以代替生产者和消费者往返于社区、Memphis 团队和第三方应用程序制作的不同应用程序和数据库。

RabbitMQ 不支持它。

流血统

跟踪流沿袭是了解消息从第一个生产者到最终消费者的完整路径的能力，包括消息在主题之间的轨迹和演变。此功能在故障排除过程中非常方便。

RabbitMQ 不提供流沿袭，但可以使用 OpenTelemetry 或 OpenLineage 框架或集成第 3 方应用程序（如 Datadog 和 Epsagon）来实现。

Memphis 使用 Memphis SDK 生成的标头为每条消息提供流沿袭，并为每条带标记的消息提供开箱即用的可视化。

自愈

RabbitMQ 需要调整、客户端制作的包装器、管理和严密监控。用户或运营商有责任确保其正常运行并按要求工作。这种方法有利有弊，因为用户几乎可以调整每个参数，这通常被认为是一个很大的负担。

Memphis 的核心功能之一是消除管理摩擦，并通过定期自检和主动重新平衡任务自主确保其正常运行并运行良好，并防止用户滥用系统。同时，系统的每个方面都可以在运行中进行配置，无需停机。

死信队列

死信队列既是一个概念，也是一个解决方案，对调试客户端很有用，因为它可以让您隔离和“回收”而不是丢弃未使用的消息以确定它们的处理不成功的原因。

在 RabbitMQ 中，来自队列的消息可以是“死信”；即在发生以下任一事件时，重新发布到交易所：

• 消费者使用 basic.reject 或 basic.nack 将 requeue 参数设置为 false 来否定消息。 
• 由于每条消息的 TTL，消息过期。 
• 消息被丢弃，因为它的队列超过了长度限制。

Memphis 的核心组成部分之一是避免意外数据丢失、实现快速开发并缩短故障排除周期。因此，Memphis 为死信提供了一个原生的解决方案，作为各种故障的站点回收站，例如未确认的消息、模式违规和自定义异常。

休息网关

为了通过 HTTP 调用为各种用例和易用性启用消息生成，Memphis 添加了一个 HTTP 网关来接收基于 REST 的请求（=消息）并将这些消息生成到所需的站点。

RabbitMQ 不支持它。

消费者内部沟通

在某些用例中，尤其是围绕微服务和流管道，不同的微服务能够相互通信以同步更改、数据到达、匹配数据流等是至关重要的。

孟菲斯目前正在尝试为消费者创建能够使用 gRPC 或共享通道相互通信的能力。

RabbitMQ 不支持它。

存储分层

Memphis 在其开源版本中提供了多层存储策略。Memphis 会将达到第一个保留策略结束的消息写入对象存储（如 S3）上的第二个保留策略，以实现更长的保留时间、可能无限和流后分析。此功能可以显着帮助降低成本和流审计。

RabbitMQ 不支持它。

通知

在 RabbitMQ 中，可以使用 AlertManager 和 Cluster 运算符进行通知，包括不同指标的松弛通知，例如未传递的消息、资源问题、滞后、性能、连接问题等。

Memphis 有一个内置的通知中心，可以根据定义的触发器（如客户端断开连接、资源耗尽、模式违规等）推送实时警报。

本站声明：
1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；

2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；

3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；

4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；

5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。