V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
majianglin
V2EX  ›  程序员

关于 MQTT 协议有几个问题想请教

  •  1
     
  •   majianglin · 52 天前 · 4525 次点击
    这是一个创建于 52 天前的主题,其中的信息可能已经有所发展或是发生改变。
    问题 1:
    我们物联网项目想使用 MQTT 作为通讯协议
    方案 1: 使用阿里云 云消息队列 MQTT 版,Java 服务器接入消息队列
    方案 2:Java 服务器自己实现 MQTT 协议
    这两个方案你们怎么选择的?有哪些优劣? 有更好的方案吗?

    问题 2:
    目前市区内的 4G 物联网网络是否稳定?是否需要加上短信通知?

    问题 3:
    Java 有哪些好用的 MQTT 开源框架做应用开发,最好是开箱即用,和业务解耦,业务程序员最好不关心协议实现
    53 条回复    2024-09-18 17:27:41 +08:00
    me1onsoda
        1
    me1onsoda  
       52 天前
    Java 自研的话 vertx 挺方便的。如果没有研发能力最好还是买个云服务 emqx 之类的,拿别人开源的不好填坑
    majianglin
        2
    majianglin  
    OP
       52 天前
    @me1onsoda 多谢了

    vertx 有点小众,还是想用 spring 全家桶。云服务这块我再研究下
    typ1805
        3
    typ1805  
       52 天前
    我们物联网项目用的是 ActiveMQ 的 MQTT 传输数据,springboot 从 MQ 订阅数据做处理的
    tool2dx
        4
    tool2dx  
       52 天前
    MQTT 算是相对简单的 TCP 协议了,可以考虑自己写一下,代码量并不多。
    LLaMA2
        5
    LLaMA2  
       52 天前
    server https://github.com/eclipse/mosquitto

    java client https://github.com/eclipse/paho.mqtt.java

    注意协议的各版本之间的差异.cs 各版本是否匹配.各类服务端实现对 qos 的支持情况

    综合而言,看项目,项目重要那就买买买,不要试图自研,自己玩或者项目甲方对 mqtt 部分功能有一定的容忍度,那就开源跑起来.


    例如一些项目中做某个报表定时推送,使用 mqtt 推送,同时也有主动 http 请求,甲方不是强烈要求送达率的话,仿真各也有 http 兜底,那就开源搞起来

    如果是某些物联网设备使用 mqtt 交互上报关键数据,那还是买买买,出了情况方便把锅顺利的抡起来
    lancelock
        6
    lancelock  
       52 天前
    为什么除了买就是自己实现,搭个开源的 broker 不行吗
    zzjcool
        7
    zzjcool  
       52 天前
    你们团队有专人维护,并且技术上有信心解决就自建,不然还是上云

    客户端的话看看 emq 的文档,我感觉 emq 在 mqtt 领域还是领先的
    StinkyTofus
        8
    StinkyTofus  
       52 天前
    买一台云服务器自己搭建 EMQX , 特别简单好用, 我觉得比阿里云的后台配置 MQTT 好用多了, 而且阿里云的 MQTT 经常出问题。
    zouri
        9
    zouri  
       52 天前
    问题一:mqtt broker 服务器可以使用开源搭建,目前这两个用户较多 emqx mosquitto
    问题二:我个人经验目前 4G 物联网足够稳定
    问题三:EclipsePaho 是一个开源项目为多种语言实现了 MQTT 客户端库,可以参考使用 https://eclipse.dev/paho/index.php?page=downloads.php
    xytest
        10
    xytest  
       52 天前
    你的需求和我最近带的项目一样。(我们有大批量的设备走 485 接口,然后通过轮询采集后通过物联网走 mqtt 上报)
    问题一:我们没有考虑自建,因为感觉后期维护成本有点高。在对比下选择了腾讯云的物联网平台原因:比阿里成本低,实现就是设备推送到腾讯云物联网平台,平台在接收消息后通过数据流传到服务器。
    问题二:网络稳定这个问题只要你信号覆盖情况下都没有问题,应该考虑的数据端的数据采集稳定,例如多设备轮询,在遇到报错的时候,是否重新查询。
    问题三:开源平台当时也试过几个还是出现了问题一的情况就是维护成本高。
    flmn
        11
    flmn  
       52 天前
    有开源的 emqx
    glitterzhong
        12
    glitterzhong  
       52 天前
    docker 直接搭建 emqx 就行
    majianglin
        13
    majianglin  
    OP
       52 天前
    多谢楼上各位的答疑解惑,学到了很多
    GooMS
        14
    GooMS  
       52 天前 via Android
    搭起来还是不麻烦的,主要看预算
    halov
        15
    halov  
       52 天前
    MQTT 还是建议使用 EMQX 搭建 , 我们公司 使用消息中间件 同时 充当 MQTT 服务器 坑挺多的
    fffq
        16
    fffq  
       52 天前
    直接使用 emqx 吧,
    mosfet
        17
    mosfet  
       52 天前
    thingsboard+emqx
    开发都省了
    vfs
        18
    vfs  
       52 天前
    除非你的时间预算很充分, 不然不要自己写 MQTT 服务器端。 我正在实现一个 MQTT Broker (公司项目), 这个协议 RFC 很简单, 真正做起来, 细节很多。
    DonaldY
        19
    DonaldY  
       52 天前
    netty 里就有,直接使用。
    andyxq
        20
    andyxq  
       52 天前
    作为从业者,我觉得 MQTT Broker 实现起来难度不算太大,但是做到较好的性能需要投入很多的精力。我测试过一些开源的或商业的 Broker, EMQX 是算是性能比较好的,开放的插件也比较多,如果没有足够的研发能力建议直接用 EMQX.
    市区用 4G 基本没问题,但是远离市区信号不好的地方可能会有频繁上下线的问题。
    gesse
        21
    gesse  
       52 天前
    问题二:
    MQTT 协议就是为这种情况开发的。
    gesse
        22
    gesse  
       52 天前
    推荐个 MQTT 本地测试、开发工具
    https://www.redisant.cn/mqtt
    yinft
        23
    yinft  
       52 天前
    一个有着从 0 到 1 自建 mqtt 服务的过来人来看,emqx 完全没问题,关键的问题是特么多这 4g 模块,我们的机器人经常就因为 4g 物联网卡的网络,跟云端丢失通讯
    yinft
        24
    yinft  
       52 天前
    @andyxq 频繁上下线真相了
    DreamLu
        25
    DreamLu  
       52 天前
    java 的话试试 mica-mqtt ,我自己开发的,现在也有很多朋友在用,集成到服务中也非常方便。几小时就能精通。
    ikas
        26
    ikas  
       52 天前
    不差钱 ->阿里云等云提供的 mqtt server
    有特殊需求->嵌入 netty mqtt
    其它->自己部署 mqtt server
    spartacussoft
        27
    spartacussoft  
       52 天前
    用 exmqx ,再结合 grpc 来与你的服务进行连接验证、订阅发布验证等交互。
    ZiLong
        28
    ZiLong  
       52 天前
    emqx 挺强大的,也非常成熟,唯一的问题时 erlang 开发的,不过一般出问题也不会排查到源码层。mqtt 确实在信号不好的地方会有断连,频繁上下线,一是在本地缓存发送失败的数据,二是通过 http 协议补偿
    xsen
        29
    xsen  
       52 天前
    动不动就说什么实现 mqtt broker 的不知道脑子怎么想的,非要挖个坑跳进去,然后慢慢填坑
    不管是基于开源的、还是商业化的,支持 mqtt broker 的方案都那么多、那么成熟

    对于楼主这样的,找个成熟、稳定的 mqtt client jar 包接入不就可以了
    tubinorg
        30
    tubinorg  
       52 天前
    emqx
    sagaxu
        31
    sagaxu  
       52 天前
    Greendays
        32
    Greendays  
       52 天前
    我的项目是用 Springboot3 配合 EMQX 做的,不过目前没上线。测试阶段用着没啥毛病。
    afxcn
        34
    afxcn  
       52 天前
    不要假定用云服务商的 mqtt 就稳定,基本的维护力量还是需要有的。#5 楼推荐的 mosquitto 还是不错的。
    dbpe
        35
    dbpe  
       52 天前
    @majianglin 不小众了..而且 2 个又不冲突....
    yazinnnn0
        36
    yazinnnn0  
       52 天前
    我用 vertx+quarkus 写过 mqtt 协议的 server(不是 broker), 挺好实现的
    不去实现 mqtt broker 的各种 qos 能力的话, 几行代码就可以跑起来
    zhufpy
        37
    zhufpy  
       52 天前
    直接跟你们的硬件开发用 socket 通信,搞啥协议,哈哈哈,我就这么干的[doge]
    iamtuzi3333
        38
    iamtuzi3333  
       52 天前
    @zhufpy socket 设备数量多了 就很烦,如果要数据要存文件的情况下,会一直占内存,
    ZZ74
        39
    ZZ74  
       52 天前
    emqx 或者 netty (已经带了 MQTT 的) 开箱即用
    zhufpy
        40
    zhufpy  
       52 天前
    @iamtuzi3333 我们上传的数据量不是很大,我都是塞队列,然后存库了,等设备多了,再换别的解决方案,哈哈哈
    sagaxu
        41
    sagaxu  
       52 天前
    @zhufpy 好多 RTU 都这么干,上报的都是 TLV 报文(tag-length-value),协议简单好实现。

    @iamtuzi3333 现在都是 NIO ,几万个设备小意思,接收性能肯定不是瓶颈,丢队列批量入库。
    nomytwins
        42
    nomytwins  
       52 天前
    我们用的 emqx docker 就行了
    Eds1995
        43
    Eds1995  
       51 天前 via iPhone
    当然 EMQX 了,干嘛要自己开发,或者 EMQX Cloud serverless 有超高的免费额度。
    Hyvi
        44
    Hyvi  
       50 天前
    问题 1:
    我们物联网项目想使用 MQTT 作为通讯协议
    方案 1: 使用阿里云 云消息队列 MQTT 版,Java 服务器接入消息队列
    方案 2:Java 服务器自己实现 MQTT 协议
    这两个方案你们怎么选择的?有哪些优劣? 有更好的方案吗?

    ------- 有人就选择方案 2 ,等其他自建或者用开源的方案。 有钱就选择方案 1 。把它理解为普通的网关一样的对待。现在还有哪个公司自建负载均衡、API-gateway 呢。

    问题 2:
    目前市区内的 4G 物联网网络是否稳定?是否需要加上短信通知?
    ------------重连肯定是要的
    问题 3:
    Java 有哪些好用的 MQTT 开源框架做应用开发,最好是开箱即用,和业务解耦,业务程序员最好不关心协议实现

    -------EclipsePaho 。
    chuunshii
        45
    chuunshii  
       50 天前
    EMQX ,搭建非常容易
    iamtuzi3333
        46
    iamtuzi3333  
       48 天前
    @zhufpy 唉,我们数据量很多,我现在是塞到队列,然后存库,写文件,设备也多,但是占用内存巨多,这个问题还得排查。
    iamtuzi3333
        47
    iamtuzi3333  
       48 天前
    @sagaxu nio 我不是很清楚这个,但是看了上个项目,用 nodejs 写的,然后有 600 个传感器,然后传感器都是主动连接服务器的 socket 丢数据上来,每次一启动就迅速把可用内存占满了,100 多 G ,现在丢给我排查,我也不懂 nodejs ,服务器只负责监听,现在搞的很烦,项目不敢起,起了就把其他项目干了,大佬,你懂这个方面的内容吗,能不能指教一下。
    iamtuzi3333
        49
    iamtuzi3333  
       48 天前
    @sagaxu 这个 debug 我试过了,nodejs 写的 koa 框架,接口层面是没有问题,就是接收数据这个模块有问题,他原本写的是开了一个端口,然后就是监听设备连接,连接了之后就接收数据,数据入库 and 写文件;问题就是它是把物理内存中的备用内存持续占满,导致可用内存持续下降,用的是 Window Server 服务器,我初步怀疑是因为连接了众多传感器,开启了非常多的异步事件连接,同时又要入库写文件,写文件数据全部积累在内存中,持续增长,它是一天凌晨时候才开启第二天的数据写入到新文件中,数据量高频且多,这个问题好难排查,之前想过用单个设备连接接收数据来测试性能,但是现在没有办法改,因为项目一启动,600 多个传感器就自动连上来发数据了;搞的我头大了,之前写这个代码的人也早就离职跑路了,留下烂摊子让我接。。。
    sagaxu
        50
    sagaxu  
       48 天前
    @iamtuzi3333 600 个 websocket 不会超过 1G 内存,你得先找出是什么数据占用了内存。

    比较有可能的情况,
    1. 接收太快来不及写入,挤压造成高内存占用,那就要提升入库性能,比如批量写。
    2. 接收到的数据入库之后,没有释放内存,这是内存泄露。
    3. 数据缓存在队列中,定期才写入(文件/DB),这种要缩短写入间隔时间。

    这种马上占满内存的,反而是最好排查的,长期慢慢爬升的比较麻烦,重现一次都要好久。
    iamtuzi3333
        51
    iamtuzi3333  
       48 天前
    @sagaxu 不是 websocket ,就是普通的 socket 通信; 1 有可能,因为数据是每秒发送一条过来,600 多个可能就有 600 多条同一时间发送过来; 2 的话内存泄漏应该不会,除了入库,它还会一直写入到文件中,此时文件应该一直持续在内存中,很大概率是这个问题; 3 这个项目写的人完全没考虑用缓存去处理数据,来一条数据就入库并且写入文件,这个问题似乎也不存在;现在不是马上占满,就是慢慢爬上,一直让可用内存变少,备用内存持续上涨,最后只剩下十几 M ,服务器运行内存是有 192GB 的,复现就只能 run 项目慢慢等,其中也不会有什么报错消息出来,这个很头疼,谢谢大佬的解答。
    coderxy
        52
    coderxy  
       48 天前
    @iamtuzi3333 大概率内存泄漏。 对服务做一下内存分析即可
    huifer
        53
    huifer  
       48 天前
    借楼发个基于 Go 语言开发的物联网开发平台。

    Go IoT 开发平台 是一个使用 Go 语言开发的免费、高效、可扩展的物联网解决方案。 该平台支持 MQTT 、HTTP 、WebSocket 、COAP 、TCP/IP 协议传输,提供轻量化的配置工具完成数据的报警功能,提供基于 JavaScript 的数据统计服务。

    Git 仓库地址: https://gitee.com/pychfarm_admin/go-iot-platform
    官网首页: http://iot-dev-egi.pages.dev/
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1068 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 19:46 · PVG 03:46 · LAX 11:46 · JFK 14:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.