树莓派组网自动检测MQTT Broker 避免重复启动的实现方法

架构老林

2026-8-29

树莓派模块化系统MQTT Broker自动发现复用落地方案

这套方案完全适配子系统独立运行、局域网协同的需求，不需要额外中心化组件，树莓派零压力运行，实测从节点上电到连上Broker的耗时不超过3秒，故障切换时间不超过5秒。

核心实现逻辑

整体流程拆成三个固定阶段，所有节点上电后严格按流程执行即可，不需要复杂的分布式共识算法，代码量控制在100行以内就能搞定。

新节点插电接入局域网后，先禁用本地MQTT Broker的默认自启（树莓派一般用Mosquitto，直接执行systemctl disable mosquitto即可），先做两层探测：

第一层：mDNS服务探测
所有成功启动Broker的节点，都通过avahi注册固定的mDNS服务，服务类型用标准MQTT服务标识_mqtt._tcp.local，服务名统一设为自定义系统标识（比如modular-iot-broker），端口固定1883。
新节点接入后直接发mDNS查询请求搜这个服务，3秒超时时间内如果收到响应，就解析出返回的IP和端口，用系统预置的通用账号尝试建立MQTT连接，1秒连接成功就判定为可用Broker，直接复用，跳过后续所有启动本地Broker的步骤。
avahi的注册配置直接参考如下内容，存成/etc/avahi/services/mqtt.service即可：
```
<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name>modular-iot-broker</name>
  <service>
    <type>_mqtt._tcp</type>
    <port>1883</port>
  </service>
</service-group>
```
探测直接调用系统命令就行，不用额外装依赖：avahi-browse -r -t _mqtt._tcp，简单正则就能解析出返回的IP地址。
第二层：同网段端口扫描兜底
如果部署环境会拦截mDNS多播包（比如部分工业交换机默认禁多播），就加个兜底逻辑：节点拿到自身IP和子网掩码后，算清同网段的所有IP，并发扫描这些IP的1883端口，单端口超时设200毫秒，并发数开50，整个网段扫完不超过2秒。扫到开放1883端口的IP就尝试发MQTT连接请求，连接成功就判定为可用Broker。

如果两层探测都没找到可用Broker，说明当前网络里没有运行中的Broker（要么是第一个接入的节点，要么之前的Broker挂了），这时候不能所有节点同时启动本地Broker，不然会出现多Broker冲突、消息不通的问题，用最简单的静态优先级选主即可，稳定性极高：

给每个子系统烧录固件时，提前写死一个唯一的优先级值：比如核心主控节点优先级设10，传感器节点设5，普通执行器节点设1，数值越大优先级越高。
探测不到Broker后，每个节点先等一段和优先级挂钩的等待时间：优先级10的节点等0-1秒随机时长，优先级5的等2-3秒，优先级1的等4-5秒，保证优先级高的节点先动作。
等待时间到了之后，再重新做一次mDNS探测，如果还是没查到Broker，就启动本地的Mosquitto服务，加载avahi的mDNS注册配置；如果已经查到其他节点启动的Broker，直接连接即可，不启动本地实例。

所有节点的MQTT客户端不要写死连接地址，加两个简单的保活逻辑就行：

当前持有Broker的节点，每1秒往固定系统主题sys/broker/beat发一个心跳包，带自身IP和Broker运行时长。
其他所有节点订阅这个心跳主题，如果连续3秒收不到心跳，或者MQTT连接断开后重连3次失败，立刻回到最开始的探测流程，重新找可用Broker，找不到就触发选主逻辑。
故障触发时同样走优先级等待逻辑，不要所有节点同时抢着启动Broker，避免冲突。

所有节点的Mosquitto配置必须完全统一：包括账号密码、ACL权限、端口、持久化配置，避免切换Broker后出现业务连不上、权限不足的问题。
不要依赖公网MQTT服务器做中转，纯局域网通信延迟能控制在10毫秒以内，而且外网断了也不影响本地子系统独立运行。
如果需要保证消息不丢，可以加个轻量同步逻辑：当前运行Broker的节点每5分钟把Mosquitto的持久化目录同步到其他节点的备份路径，万一Broker节点直接掉电，新选出来的Broker可以直接加载最近的备份文件，消息不会丢。
本地Mosquitto服务的启停完全由自定义探测脚本控制，不要开开机自启，避免上电就启动导致多Broker冲突。

内容的提问来源于stack exchange，提问作者Garrett Reynolds