我的mqtt协议和emqttd开源项目个人理解(26) - 产品开发遇到的问题解答,关于订阅和上下线插件

我 17:27


请问大咖们,之前群里提到“EMQ中CPU是公平分配给MQTT会话,大量pub消息到一个订阅,订阅不会拿到更多cpu,最终导致消息累积。”这个问题在emq v1和v2版本都存在吗?大概每秒发多少条数据就会出现这个现象?


大梁先生 17:53


这和机器配置有一定关系的 而且不要做这种设计呀 干嘛都投给一个topic


我 17:59


那应该怎么设计?因为我们的场景就是单一的行业,单一服务器订阅,然后数据呈现在web


大梁先生 17:59


如果真要这样做 就得把route中的hash分布改下 但是 这样就不能保证有序了


大梁先生 18:01


只是我个人看法 最好遵循emq的设计思想吧 可以再询问下大佬


我 18:02


难道是两万个终端publish,我后台就用两万个主题订阅?


大梁先生 18:05


一个不够你可以起100个 rewite规则对上不就好了


我 18:09


我还没有去了解rewrite的用途


大梁先生 18:10


@我?有没有觉得emq设计很强大 只是自己想的太少[呲牙]


我 18:11


是,emq思想很厉害


我 18:14


现在我的问题是两万客户端都是“x”主题,已经出货了,那怎么办


我 18:15


都是“x”主题publish发布,后台一个sub订阅所有


helloworld 18:17


没有其他的 主题,性能不是应该更高了吗?不需要查找主题。


柠檬先生 18:23


但是消息投递效率就低了,这样造成设备越多,投递就效率就越低,所有设备都收到了


大梁先生 18:23


他是阻塞到向另外一个服务发订阅消息那里了


柠檬先生 18:24


N对1的关系,CPU调度压力就大了


大梁先生 18:26


嗯嗯 而且 向别的服务发送也没必要用mqtt


helloworld 18:27


也是。下行就不行了。


我 18:27


那我的问题如何解决?已经出货了,都是“x”主题


helloworld 18:27


才两万个 少下行一些消息。应该问题不大把


我 18:28


要从长计议啊,未来还要出货


柠檬先生 18:29


你用消息组件吧


柠檬先生 18:29


不要订阅了


我 18:29


什么是消息组件?v2有这个功能?


柠檬先生 18:29


你是要收设备上报么


我 18:30



大梁先生 18:30


方法挺多的都要改代码


柠檬先生 18:30


V2支持各种差件


柠檬先生 18:30


插件


柠檬先生 18:30


没研发能力就花钱买商业的


我 18:30


不订阅怎么拿数据


柠檬先生 18:32


有publish钩子


柠檬先生 18:32


把消息转到消息中间件


我 18:36


中间件也要支持mqtt协议吧


我 18:36


kafka能支持mqtt?


柠檬先生 18:37


都支持的


柠檬先生 18:37


不用支持mqtt协议


柠檬先生 18:38


投到kafka就行


柠檬先生 18:38


坑也多


柠檬先生 18:38


[呲牙][呲牙][呲牙]


我 18:41


是的,我说觉得投到kafka应该不稳定,坑多多


陈先生 21:11


有个问题请教高人们,为什么冲突被挤下线不掉用disconnect这个钩子?


陈先生 21:13


我觉得不科学 被挤下线 也是下线,为什么disconnect 钩子就不掉用呢?基于什么考虑?


陈先生 21:15


本来想在离线狗子里面做些事情的,后来发现被挤下线的完全不进入disconnect钩子里面


我 21:17


是的,同问。我也发现了这个问题。不好统计在线和离线的终端数量


柠檬先生 21:18


挤下线,不影响数量吧


柠檬先生 21:18


重新上线了


我 21:18


就是hook那个插件钩子,捕获上下线的


柠檬先生 21:19



柠檬先生 21:19


你这样就不准了


柠檬先生 21:20


挤下线直接关了进程,走不到钩子里


柠檬先生 21:20


光靠这个不靠谱


我 21:21


那如何统计在线终端数目?


我 21:21


我目前仅仅在上线钩子 1,下线钩子-1


我 21:21


但是总不对


柠檬先生 21:26


用emq_modules模块,结合存储来做


柠檬先生 21:27


这是最准的


我 21:28


我当前的问题就是clientid反复重启上线,id冲突时,总是执行了connect 1,但是从不执行disconnect-1,导致越加越多。


陈先生 21:33


没调用钩子 这个现象知道,我好奇的是为什么不进入那个钩子?对被挤下线的客户端来说就是disconnect


Gilbert 21:34


不是 disconnect ,进程都关了,都没有走发送 disconnect 报文的步骤,这叫非正常断连


陈先生 21:36


被挤下线的 为什么会被认为非正常断?


我 21:37


是的,个人认为被挤下线,也应该走钩子的disconnect函数


Gilbert 21:37


因为没发送 disconnect 报文


Gilbert 21:38


mqtt 协议本身是有disconnect 报文来通知客户端连接断开的


Gilbert 21:38


emq 也做了


柠檬先生 21:42


Emq做的没错


柠檬先生 21:43


我们上千万设备都没出现过乱掉


[皱眉][皱眉] 21:45


[呲牙]360和惠普都开始用emq了,这公司马上就可以纳斯达克上市了


柠檬先生 21:47


所以说EMQ对MQTT生态贡献太大了


柠檬先生 21:48


上周参加MQTT TC会议,MQTT 5 基本定稿了


柠檬先生 21:48


但是几个主席都是IBM的,主推还是他们自家的HiveMQ


柠檬先生 22:07


MQTT 5 能做很多事情,物联网设备形态太多了


柠檬先生 22:12


物联网用的多的还有AMQP


柠檬先生 22:14


哈哈,是吧,MQTT 是IBM 90年代设计的,那个时候网络更烂,都能搞得定,说明MQTT还是够灵活稳定的


上一篇:短视频APP源码,最“亲民”的娱乐软件


下一篇:短视频APP开发,消除需求壁垒后的圈层经济