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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/libaineu2004/article/details/83658058

我 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还是够灵活稳定的

猜你喜欢

转载自blog.csdn.net/libaineu2004/article/details/83658058