当前位置: 首页 > news >正文

车企需求验证:smart - mqtt 高可用比性能更重要

突发!车企需求验证:smart - mqtt 高可用比性能更重要

在维护 [smart - mqtt] 的这些年,常有人问:“这个 Broker 单机能支撑多少连接?”说实话,这问题不好答,不同业务场景和硬件配置,结果不同。

但前段时间,一位国内头部车企技术人员的问题让我印象深刻:“单机已经够用了,但我们还是要做集群”。沟通中我询问业务规模,对方称大概几万,单机轻松顶住,但有单点故障问题,且有高可用部署要求。

这让我意识到,对真正的生产系统,性能是工程问题,高可用才是业务问题。比如 Broker 所在服务器宕机、系统升级重启服务、节点异常退出,这些比“单机能扛多少连接”更重要。于是我决定本地复现高可用架构,验证“当 Broker 真正发生故障时,smart - mqtt 是否还能正常工作”。

其实这次验证不意外,设计 [cluster - plugin] 时,我就在想,若 smart - mqtt 用于企业生产环境,最先遇到的问题是什么?答案不是性能,而是高可用,如设备连不同 Broker 后消息跨节点投递、节点故障后业务持续运行、不停机完成系统升级等问题。基于这些预判,smart - mqtt 设计之初预留集群扩展能力,演化出 `cluster - plugin`,当初像面向未来的准备,这次车企真实需求让我明白,那些“暂时用不上”的设计,终会体现价值。

为模拟实际生产环境,我本地搭建环境:3 个 smart - mqtt Broker 节点、1 个 HAProxy 负载均衡实例、多个 MQTTX 客户端。整体架构如下:

MQTT Client │ ▼ SLB / HAProxy │ ┌────────┼────────┐ ▼ ▼ ▼ Broker Broker Broker ╲ │ ╱ ╲ │ ╱ cluster - plugin
需说明,生产环境常用云厂商 SLB,本次用 HAProxy 仅本地模拟负载均衡。很多人初接触 MQTT 集群,以为加负载均衡、多部署 Broker 就行,实则不然。假设 Client - A 连 Broker - 1 订阅 `car/+/status`,Client - B 连 Broker - 2 发布 `car/001/status`,若 Broker 独立,Broker - 2 不知 Broker - 1 有匹配订阅,Client - A 收不到消息。所以真正可用的 MQTT 集群需连接高可用和消息高可用,HAProxy(SLB)负责客户端接入,cluster - plugin 负责跨节点消息同步,即 SLB 送客户端进来,cluster - plugin 送消息过去。

为保证实验可复现,我将 `docker - compose.yaml` 和 `haproxy.cfg` 提交到 smart - mqtt 官方仓库。用 Docker Compose 启动 3 个独立 Broker 节点,但它们还是“孤岛”。接着登录各 Broker 管理后台启用 `cluster - plugin`,因实验在 Docker 内部网络,节点通过容器名称通信。完成配置保存生效后,各 Broker 节点建立集群连接,3 个独立节点组成 MQTT 集群。

环境准备好后,我用 MQTTX 创建多个客户端连接,HAProxy 分发连接到不同 Broker 节点,系统看似正常。但真正的高可用是故障发生时仍能服务。于是我执行 `docker restart mqtt - broker - 1` 模拟 Broker 节点异常退出。几秒内,HAProxy 识别故障节点,新连接不进 Broker - 1,MQTT 客户端重连,cluster - plugin 跨节点投递消息,其他 Broker 节点服务。Broker - 1 恢复后重新加入集群,业务未因单节点故障中断。

这次验证让我确信,对企业用户,MQTT Broker 价值不只在性能指标,几万级连接对现代 Broker 不难,真正决定能否进生产环境的是面对故障的表现,如节点下线时业务是否中断、客户端能否恢复、消息能否送达,这些比“单机能支撑多少连接”更重要。

正如车企用户所说:“单机也能轻松顶住,只不过有单点故障问题。”这也是很多企业推进 MQTT 落地的问题。性能决定系统上限,高可用决定系统能否承载业务。做开源项目常如此,很多能力诞生时无明确场景,但方向正确,总会遇到需要它的人。`cluster - plugin` 对 smart - mqtt 或许就是提前准备。希望这次验证能为评估 MQTT 高可用方案的团队提供参考,真正值得信赖的系统是故障时仍可用。

如果你的团队正在评估 MQTT 技术选型,或者面临高可用、集群部署、性能优化等问题,也欢迎与我们交流。

社区资源
-官方文档
-GitHub 仓库
-Gitee 仓库

http://www.cnnetsun.cn/news/2993382.html

相关文章:

  • 使用Gemini显示“出了点问题”又或者“Somethingwent wrong”出错?
  • 客服机器人什么算好?电商AI客服系统选型,90%的商家都踩过这7个坑!
  • 扣子(Coze)(1):零基础入门指南
  • 进程的五态模型
  • 现场停线没人理?这套安灯管理系统经验,让响应速度直接翻倍
  • Django毕设选题推荐:基于 Django-Vue 架构的试题库管理系统设计与开发【附源码、mysql、文档、调试+代码讲解+全bao等】
  • AI工程范式的又一次演进:Harness Engineering
  • AI生成前端如何摆脱机械感?OpenClaw+Next.js人格化渲染实践
  • DMXAPI+Qwen3.7-Max智能体实战:从PLC文档化看AI编程落地
  • Salt Master生产部署指南:Ubuntu 24.04从零安装与故障排查
  • 嵌入式系统Flash存储与COP看门狗:高可靠性设计的核心机制与实践
  • OpenClaw本地AI工作流引擎:解压即用的原理与Windows 11适配深度解析
  • AMP HTML:移动端内容秒开的结构化网页契约
  • BGPalerter实战:Ubuntu 18.04上部署秒级BGP路由异常告警
  • Qwen 3.6-Plus:面向Node.js开发者的国产编程AI落地实践
  • AI道德对齐:机器决策中的价值观匹配与挑战
  • 嵌入式音频接口SSI配置详解:I2S与AC97模式实战与调试
  • Ubuntu 18.04 部署 Discourse 的 Docker 化实践与故障排查
  • Ubuntu 18.04 + GitLab 13.12.15 稳定部署实战指南
  • PHP伪协议在文件包含漏洞中的实战应用与防御策略
  • OpticsGPT:大语言模型如何革新光学设计流程
  • Ubuntu 20.04 部署 code-server 生产级远程开发环境全指南
  • Claude Code Skills 源码深度解析:AI原生工作流的契约式执行架构
  • IRIS2与Starlink低轨星座技术架构、仿真对比与战略差异深度解析
  • Kubernetes Ingress HTTPS自动化:cert-manager+NGINX实现Let’s Encrypt端到端证书管理
  • AI编程助手实战:从提示工程到优雅代码的完整协作指南
  • MAAC扩展应用:如何将注意力机制应用到自定义多智能体任务
  • hongyangWeixinArticles项目实战教程:如何将公众号文章转化为结构化知识库
  • 如何快速上手MCP-Security-Checklist:初学者完整教程与实战演练
  • Medium Editor Markdown未来展望:Markdown编辑器的演进趋势与技术挑战