​EMQ X VS RabbitMQ：两大消息服务器 MQTT 性能对比全解（下）

造成差距的原因主要有三个：节点间通讯的方式、消息流架构的方式、队列的使用。

节点间的通讯

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 要比自己原有的成绩更好。