单节点 TBMQ 实现每秒 300 万条消息吞吐量

• 测试方法
• 使用的硬件
• 测试总结
• 运行测试
• 如何复现测试
• 结论

对于MQTT broker，高负载下的最佳性能至关重要。 本文介绍TBMQ的一项性能测试，我们验证了其能够以单位数毫秒延迟处理每秒300万条消息的吞吐量。 仅使用单节点，我们便达到了TBMQ的能力极限。

测试方法

我们在 EKS 集群中部署单个TBMQ节点，配合3个 Kafka 节点和 RDS 实例，建立了性能测试环境。该配置为我们的性能测试提供了基础。

在本测试中，我们引入了100个发布者，每个负责每秒发布10条消息。 重要的是，每个发布者在其各自的topic上发布消息，遵循 "CountryCode/City/ID" 格式，其中 “ID” 为每个发布者的唯一标识符。 单条 “publish” 消息大小约为66字节。该方法使我们能够模拟不同的数据源。

为评估TBMQ高效分发消息的能力，我们引入了3,000个订阅者组成的网络。 每个订阅者订阅topic过滤器 "CountryCode/City/#"，表示接收所有发布者发布的所有消息。 这种广泛的消息分发考验了broker的能力。

在30分钟的性能测试期间，我们验证TBMQ是否能够稳定处理大量消息负载， 而不会出现性能下降或资源耗尽。

使用的硬件

测试总结

在单节点上运行的TBMQ成功处理了每秒300万条消息的吞吐量，展现出出色的性能。 这一显著成果彰显了TBMQ在实际场景中的可靠性。

同样令人瞩目的是broker的平均消息延迟仅为 7.4毫秒。 该低延迟证明了TBMQ在高负载下仍能保证消息及时送达。

以下表格总结了测试的关键要素和结果，便于查阅。

经验总结

我们的测试凸显了为可靠性和可扩展性优化TBMQ的重要性。 结果表明broker能够轻松处理大量消息负载，是消息分发关键场景的理想选择。

我们观察到TBMQ的资源管理能力及其在高负载下保持稳定的能力。 这些观察可帮助用户配置以获得最佳性能。

重要说明： 在本性能测试过程中，我们对多种实例类型进行了实验。 尽管我们为TBMQ选用了AWS m7a.8xlarge 实例类型，但需强调的是，在 m7a.4xlarge（16 vCPU，64 GiB RAM）实例上也取得了不俗的成绩。 该配置实现了 14.2 ms 的平均消息延迟，同时保持 90% 的CPU使用率。 这些结果表明TBMQ在不同实例类型上都具有良好的灵活性和性能潜力， 使用户可以根据自身需求选择最合适的配置。

运行测试

测试agent由性能测试节点（runner）集群和监督这些runner的编排器组成。 为实现各自角色，我们部署了1个发布者和6个订阅者Kubernetes pod，另有一个pod作为编排器。 值得注意的是，每个发布者和订阅者pod分配在不同的AWS EC2实例上。

有关我们测试配置中使用的AWS EC2实例的完整视图，请参阅以下图片：

测试开始涉及在客户端与TBMQ之间建立连接。订阅者客户端迅速建立订阅，而发布者客户端开始预热阶段。 当所有runner就绪后，编排器通知集群已就绪，消息发布随即开始。

经过一段时间的处理后，我们可以通过JMX、htop、Kafka UI以及AWS CloudWatch等监控工具进行更全面的评估。

监控工具显示平均CPU负载约为 54%。 这表明TBMQ具备较大的处理能力，能够高效处理更高的消息负载并应对消息投递峰值。

如何复现测试

我们建议参阅我们的安装指南，其中包含在AWS上部署TBMQ的逐步说明。 此外，您可以查看包含本性能测试期间运行TBMQ所用脚本和参数的 branch， 以深入了解我们的配置。 对于实际执行性能测试，我们提供专用的性能测试工具， 可生成MQTT客户端并模拟所需的消息负载。 配置性能测试时，您可以根据具体需求查看并修改 发布者 和 订阅者 的配置文件。

结论

TBMQ在单节点上成功以每秒300万条消息、平均延迟仅7.4毫秒的性能运行，再次印证其作为稳健且可扩展的MQTT broker的地位。 该成果表明TBMQ已准备好应对高要求工作负载，是依赖高效消息分发的应用的可靠选择。

我们将继续探索TBMQ的能力，持续提升性能和可靠性。 期待在未来分享更多insights和性能结果。

如有反馈，欢迎在 GitHub 关注我们以了解最新动态。