关于rabbitmq:EMQ-X-与-RabbitMQ-消息服务器-MQTT-性能对比下

在上篇文章中，咱们采纳雷同的硬件资源别离对 MQTT 音讯服务器 EMQ X 和 RabbitMQ 进行了压力测试。结果表明：在「多对一」场景中，EMQ X 和 RabbitMQ 相比并没有太大差异；而在「一对多」场景中，RabbitMQ 则较 EMQ X 产生了较为显著的差距。

本期文章中咱们将对这一后果进行进一步的解析。

造成差距的起因次要有三个：节点间通信的形式、音讯流架构的形式、队列的应用。

节点间的通信

RabbitMQ – 委托架构

RabbitMQ 应用了 Erlang 语言的分布式连贯，即每个节点之间两两相互连贯，每个节点用一个繁多的链接连贯着另一个节点。在图中的状况下，三个节点顺次连贯；当节点之间须要通信时，一条音讯须要通过这个繁多链接从一个节点发送到另一节点。

在扇出（fan-out）的例子中，失常来讲你须要将音讯推送到所有节点的队列上。RabbitMQ 应用的优化形式则是：你的音讯只须要发送一次，之后其内置的代理委托框架会将这一条音讯派送并且发到其余节点的队列上。这个过程中，音讯是有序发送的，所以保障了音讯在不同队列里都是雷同的程序。

然而这个计划也不是美中不足的，因为你会将所有的音讯只发送一次，在散发工作都依附同一个委托过程。而且 RabbitMQ 抉择这个代理过程的策略是依据发布者的哈希算法。所以，当如果你只有一个发布者，所有的音讯都会被始终推送到单个的委托代理过程。

EMQ X – Gen_RPC

在 EMQ X 中有个精妙的设计：其不仅存在着分布式连贯，还存在着 Gen_RPC。散布连贯和 Gen_RPC 各司其职，前者用于替换 Mnesia 的数据信息，后者则只实用于音讯的转发。每当你须要从一个节点向另一个节点公布一个音讯的时候，EMQ X 不是从新主动生成新的节点间链接（默认 1 个连贯），再通过这些新的连贯去解决把一个音讯从一个节点推送到另一个节点的工作。而是依附针对此场景顺便设计的，专有的 Gen_RPC 连贯来解决这个音讯推送的工作。所以在扇出（一对多）的例子中，这些链接会被齐全无效地利用。

但这种设计在网络分区环境中其性能有可能受到影响，RabbitMQ 节点之间只有一个分布式连贯，所以当连贯断开造成脑裂时，愈合修复的工作将会更简略。

音讯流

MQTT 插件

RabbitMQ 在应用 MQTT 插件后会监听应用 MQTT 协定公布的音讯。失去音讯之后，音讯被解析，之后再通过 AMQP 协定进行转化，最初才会被发送到 RabbitMQ 上。

如果要发送一条音讯，须要通过套接字后进入 mqtt_reader，接下来再进入下图所示的所有过程。然而如果要在同一条通道里同时接管刚刚发送的这条音讯，所有上图所示的过程则须要反着从新进行一次，包含 mqtt_reader。其中，mqtt_reader 不仅负责了读，也负责了写。

AMQP

AMQP 场景则不同，每条音讯都被一个 reader 读取，一个 writer 写入。这两条通道读写独立，reader 只负责读内容，而 writer 只负责写内容，它们各司其职、互相独立。而惟一的通道 channel 则是一个主 Erlang 过程，其负责着音讯的替换。

可见 RabbitMQ 在 MQTT 场景中存在的显著的设计问题会导致性能降落，那么如果引入 AMQP 模式的 RabbitMQ 测试用例将会如何呢？将 RabbitMQ 调制成应用 MQTT 插件的和应用繁多 AMQP 的模式应用，再比照 EMQ X 在压力测试下的状况，能够看出 EMQ X 在所有测试中仍是更胜一筹，但总体来说应用 AMQP 模式的 RabbitMQ 要比本人原有的问题更好。

多对一

此场景中 RabbitMQ 与 EMQ X 曾经有了靠近的性能体现。

一对多

但如果在 fan-out（一对多 ) 场景里，EMQ X 依然具备显著劣势，但 RabbitMQ（AMQP）的差距曾经显著放大。

队列

以上的测试均应用了 QoS 1 的音讯。当发送 QoS 1 的音讯时，这些音讯每次都要作为可长久化的备份保留在硬盘上。所以队列空间的应用也尤为重要。

RabbitMQ

RabbitMQ 成熟地应用了一个默认的队列空间执行形式（能够被替换成其余队列应用）。这个可变队列在音讯的长久度和给客户端发送音讯的时延里做了平衡。然而在最坏的状况下，一个音讯可能会被存入内存。不过这也帮忙了 RabbitMQ 在解体重启之后能够让服务器再上线，并且所有的客户端还可重连且收到原来长久化的音讯。

EMQ X

EMQ X 对队列的实现形式非常简单，即在内存中应用了优先队列。如果发来的音讯无奈推入接收者的队列，则这个音讯会被丢掉。在 EMQ X 中，只有用一些其余长久化的插件能力使音讯长久化保留，这些性能在商业版中提供。

EMQ X 的设计初衷是将接入层独立，所以将音讯长久化的问题留给了后端实现。这一问题在将来具备持久性会话的版本中会解决（persistence session）。

节流

RabbitMQ – 控流

RabbitMQ 采纳了一种比拟有名的控流机制，它给每一个流程了一个信用值，如下图所示。假如说咱们的服务端接管到了一个音讯并由 reader 进行了读取后，这条音讯被送到 channel。这个过程将会生产掉 reader 和 channel 的相应的信用值。这样一来，就能够通过使两方信用值放弃匹配同步的办法实现不超额的发送了。

这其实是一个不错的解决方案。构想咱们有许多的用户，即有许多的队列，每发送一条音讯就意味着将要将这条音讯分发给许多的队列，这会重大影响 RabbitMQ 实例。然而，这一套流程会阻止 RabbitMQ 再持续读区接收缓冲区的音讯——因为发送缓冲区曾经快满了！

EMQ X – 限流

EMQ X 的节流次要是靠限度读取一方的流量去实现的。首先，依据预设，将会一次从套接字内读取 200 条音讯。当这些音讯被齐全收到了之后才会一一将他们解决。一旦套接字报告它曾经达到了读取一方的最大限额，它将会查看有发布者的数量和曾经被浏览的字节数量，并依据这个数值去休眠一段时间。接收缓冲区最终会被填满，发布者依据 TCP 协定中航行窗口的要求也将不会再公布任何内容。

总结

以上就是这个横向评测的后果和剖析。最终的赢家很难断言，然而如果就服务器的性能上来讲，EMQ X 必定是稍逊一筹的。不过 RabbitMQ 也有它独特的劣势。

EMQ X 的设计准则

EMQ X 在设计上，首先拆散了前端协定 (FrontEnd) 与后端集成 (Backend)，其次拆散了音讯路由立体 (Flow Plane) 与监控治理立体 (Monitor/Control Plane)：

1. EMQ X 外围解决的问题：解决海量的并发 MQTT 连贯与路由音讯。
2. 充分利用 Erlang/OTP 平台软实时、低延时、高并发、散布容错的劣势。
3. 连贯 (Connection)、会话 (Session)、路由 (Router)、集群 (Cluster) 分层。
4. 音讯路由立体 (Flow Plane) 与管制治理立体 (Control Plane) 拆散。
5. 反对后端数据库或 NoSQL 实现数据长久化、容灾备份与利用集成。

EMQ X 的零碎分层

1. 连贯层 (Connection Layer)：负责 TCP 连贯解决、MQTT 协定编解码。
2. 会话层 (Session Layer)：解决 MQTT 协定公布订阅音讯交互流程。
3. 路由层 (Route Layer)：节点内路由派发 MQTT 音讯。
4. 散布层 (Distributed Layer)：散布节点间路由 MQTT 音讯。
5. 认证与访问控制 (ACL)：连贯层反对可扩大的认证与访问控制模块。
6. 钩子 (Hooks) 与插件 (Plugins)：零碎每层提供可扩大的钩子，反对插件形式扩大服务器。

而 RabbitMQ 则更相似于 Kafka 的音讯队列缓存设计。倡议在 IoT 我的项目中将两者联合应用。

版权申明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/emqx-or-rabbitmq-part-2

技术支持：如对本文或 EMQ 相干产品有疑难，可拜访 EMQ 问答社区 https://askemq.com 发问，咱们将会及时回复反对。

更多技术干货，欢送关注咱们公众号【EMQ 中文社区】。