如何发起 MQTT 亿级连接和千万消息吞吐性能测试

简介：MQTT 协议凭借简单易实现、支持 QoS、报文小等特点，占据了物联网协议的半壁江山。

作者：亦炎

随着 5G 时代的来临，万物互联的伟大构想正在成为现实。联网的物联网设备在 2021 年已经达到了 120 亿，在未来两年，仅智能水电气表就将超过 10 亿。在如此大的物联网需求下，海量的设备接入和设备管理对网络带宽、通信协议以及平台服务架构都带来了很大挑战。如何做好以 MQTT 为代表的物联网协议性能测试，也就显得尤为重要。那么，我们该如何做好 MQTT 的性能测试呢？

什么是 MQTT 协议

MQTT 是基于 TCP/IP 协议栈构建的异步通信消息协议，是一种轻量级的发布、订阅信息传输协议。可在不可靠的网络环境中进行扩展，适用于设备硬件存储空间或网络带宽有限的场景。使用 MQTT 协议，消息发送者与接收者不受时间和空间的限制。

对于物联网协议来说，必须针对性地解决物联网设备通信的几个关键问题：其网络环境复杂而不可靠、其内存和闪存容量小、其处理器能力有限。MQTT 协议凭借简单易实现、支持 QoS、报文小等特点，占据了物联网协议的半壁江山。

MQTT 的发布订阅模式

发布订阅模式区别于传统的客户端-服务器模式，它使发送消息的客户端（发布者）与接收消息的客户端（订阅者）分离，发布者与订阅者不需要建立直接联系。我们既可以让多个发布者向一个订阅者发布消息，也可以让多个订阅者同时接收一个发布者的消息，它的精髓在于由一个被称为代理的中间角色（或称为 MQTT Broker）负责所有消息路由和分发的工作。传统的客户端-服务器模式可以实现类似的效果，但是无法做到像发布订阅模式这样简洁和优雅。

发布订阅模式的优点在于发布者与订阅者的解耦，这种解耦表现在以下两个方面：

空间解耦：订阅者与发布者不需要建立直接连接，新的订阅者想要加入网络时不需要修改发布者的行为。
时间解耦：订阅者和发布者不需要同时在线，即便不存在订阅者也不影响发布者发布消息。

为什么要做 MQTT 性能测试

MQTT 性能测试主要帮助我们做到如下内容：

1. 摸清 MQTT 核心指标

不同网络环境下，消息端到端的时延
MQTT Broker 同时保持的最大连接数
MQTT 收发消息的 TPS

2. 辅助 MQTT Broker 选型

物联网行业里可选的 MQTT Broker 不胜枚举，除了经典的 Mosquitto 和 AWS、Azure，百度云、阿里云、IBM 等几个提供物联网 MQTT 接入服务的产品外，可用于商业生产的 MQTT Broker 还有多款。

但是每一款 MQTT Broker 的系统性能与适用场景都不尽相同。例如，EMQ 单机性能较高，单机支持百万级并发，集群支持千万级并发，优势在于高并发连接与高吞吐消息的服务能力；HiveMQ 单机性能相对较差，有一定高并发连接与高吞吐消息的服务能力。

通过 MQTT 性能测试，我们可以更加精准的选择合适的 MQTT Broker。

业界一般如何做 MQTT 性能测试？

MQTT 性能测试的难点在于能够同时发起并保持海量的连接。

目前最常见的 MQTT 性能测试方式，是基于 JMeter 的 MQTT-Xmeter 插件实现的。该插件的底层原理就是每个线程都模拟一个 MQTT Client，向 MQTT Broker 发送连接请求。然而 JMeter 的线程模型（一个并发就是线程）决定了，想要发起海量的连接请求，施压机就必须创建同等数量的线程，不仅造成资源的严重浪费，还限制了单个施压机能够发起的总连接请求数。阿里云的性能测试 PTS 允许单个线程发起并保持最多 100 个，单台施压机最大 5 万个，单次压测最大 1 亿个 MQTT 连接数。

使用 PTS 可以帮助用户轻松发起千万乃至亿级的 MQTT 连接，节省大量时间成本和机器成本。

如何使用 PTS 发起 MQTT 亿级连接和千万消息吞吐性能测试

使用步骤

1、创建场景。我们在 PTS 控制台的【压测中心】->【创建场景】中创建 MQTT 压测场景；

2、场景配置。PTS 支持建立连接、发布消息、订阅消息和关闭连接四种测试节点。用户若仅需测试 Broker 支持的最大连接数，可以只创建建立连接节点。

对于阿里云的 MQTT 实例，用户只需要打开签名鉴权开关，填入 AccessKey ID、AccessKey Secret 和实例 ID 即可，PTS 会动态生成用户名和密码。PTS 支持指定单并发连接数，以及均匀递增、阶梯递增和固定压力三种流量模型。用户可以通过调整压测中并发数，来控制 MQTT 连接数的增长速率。

场景配置示例：1 万个 MQTT 连接作为 pub 客户端发送消息，每个 pub 客户端每秒发送 1 条 QoS0 消息；99 万个 MQTT 连接作为 sub 客户端接收消息，每个 sub 客户端每秒接收 1 条 QoS0 消息。因此，总的消息发布吞吐率为每秒 10000，总的消息接收吞吐率达到每秒 100 万。