RabbitMQ MQTT插件源码级性能优化

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了RabbitMQ MQTT插件源码级性能优化，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1248字，纯文字阅读大概需要2分钟。

内容图文

最近在搞物联网平台，海量级别的消息Push导致MQ处理速度下降，对MQ进行单队列性能压测，结果很不如意啊！下游设备是通过NB模块和ESP进行双链路数据采集，由于场景就是抄表，但是下游设备太多，老板也没给多少银子买云服务，所以只能自己研究一波儿了~

抄表也就意味着单Topic，进行测试的时候单个Topic消费端TPS到1.7w/s，大量的消息处于unconfirmed未确认状态，达到了TPS上限，然后通过新增消费端仍然是无法解决，那么就将性能瓶颈的视角转向了MQ服务。

对于瞬间大量并发的数据平台来说，1.7w感觉有点少，之前的处理对策是分批汇报，但是这次数据量太大，导致分批汇报也会出现这种问题。

由于之前的项目对AMQP协议有进行压测，很明显MQTT比AMQP低很多。研究了一下rabbitmq_mqtt插件，发现是将MQTT转化为AMQP放入消息队列。那么是转换过程中出现了性能瓶颈吗？

研究发现：和QOS有关，delivery_mode在源码中是2，这表示每一条消息都要走磁盘I/O。那么为啥这个插件要这么设计呢？QOS=1表示消息最少到达一次，也就是失败后可以重发一次，消息持久化机制在Server挂掉的情况下也会保证消息不丢失，确保了QOS1的特性。但是抄表数据时累加的，而且考虑到某些数据的汇报实时性，因此放弃QOS=1方案：

// 修改src/rabbit_mqtt_processor.erl
delivery_mode(?QOS_1) -> 1;

然后进行测试，结果可达4w/s的TPS，同样硬件客户端代码也进行了修改，使得QOS等于0，那么表示这个消息处理平台只支持QOS=0了，这样虽然有可能损失部分数据，但是解决了消息堆积问题。

内容总结

以上是互联网集市为您收集整理的RabbitMQ MQTT插件源码级性能优化全部内容，希望文章能够帮你解决RabbitMQ MQTT插件源码级性能优化所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---