一、 场景痛点：数据丢包引发的验收危机

在最近的一个化工厂改造项目中，我们遇到了一个经典的“弱网环境”挑战：

• 现场环境：设备分布在大量金属罐体之间，4G 信号只有一格，Wi-Fi 覆盖存在盲区。

• 业务需求：必须以 1Hz 的频率采集压力和温度数据，数据存入时序数据库（TDengine/InfluxDB）。

• 致命问题：现场网络每天会有 10-20 次的随机抖动或短暂断连。直连云端的方案导致数据库中出现大量“空洞”，数据完整性仅为 85%，客户拒绝验收。

很多初级工程师的第一反应是：“在代码里写个本地文件缓存，断网了写文件，联网了读文件。”

。在嵌入式网关的 Flash 存储上频繁读写文件会极快耗尽寿命，且文件锁处理极其复杂。

本文将演示一套标准的“Store & Forward（存储与转发）”架构，不写一行缓存代码，仅通过配置 MQTT 桥接即可解决问题。

二、 架构拓扑设计

我们采用**“边缘轻量级 Broker + 云端企业级 Broker”**的级联架构。

• 边缘侧（Edge）：运行 NanoMQ（超轻量 MQTT Broker）。它负责接收本地 PLC/传感器的数据，并维护一个“桥接队列”。

• 传输层：配置 MQTT Bridge，开启 clean_start=false 和 QoS 1。

• 云端/中心侧（Cloud）：运行 EMQX Enterprise EMQX企业 EMQX企业，负责高并发接入和数据持久化。

PLC/采集程序 -> [本地 NanoMQ (缓存队列)] --(弱网/断网阻塞)--> || --(网络恢复)--> [云端 EMQX] -> 数据库

三、 核心实施步骤 (Copy & Paste)

我们假设您使用的是基于 Linux 的工业网关（如 Moxa UC系列 或 鲁邦通 R3000）。

1. 边缘侧部署 (Docker Compose)

在边缘网关上，我们不需要部署沉重的 EMQX，而是使用 NanoMQ。请保存以下内容为 docker-compose.yml：

version: '3.8'

services:
  nanomq:
    image: emqx/nanomq:latest
    container_name: edge-broker
    restart: always
    ports:
      - "1883:1883" # 供本地采集程序连接
    volumes:
      - ./nanomq.conf:/etc/nanomq.conf
    environment:
      - NANOMQ_Log_Level=warn

2. 关键配置：配置“断网缓存桥接”

这是最核心的一步。创建 nanomq.conf，重点关注 sqlite 缓存配置。NanoMQ 支持将未发送的消息缓存到磁盘（SQLite），防止内存溢出。

# 基础监听
listeners.tcp {
  bind = "0.0.0.0:1883"
}

# 桥接配置：连接到云端 EMQX
bridges.mqtt.name {
  server = "tcp://your-cloud-broker-ip:1883"
  proto_ver = 4
  keepalive = 60s
  clean_start = false  # 关键：保持会话，确保断连后状态同步
  
  # 转发规则：将本地所有 'sensor/#' 主题的数据转发到云端
  forwards = [
    {
      remote_topic = "factory/edge01/sensor/#"
      local_topic = "sensor/#"
    }
  ]

  # *** 核心：断网缓存策略 ***
  # 当连接断开时，最大缓存消息条数
  queue.max_len = 10000 
  # 使用磁盘缓存（SQLite）防止网关内存爆满
  disk_cache = on
  disk_cache_path = "/tmp/nanomq_cache"
}

3. 验证效果

1. 启动容器：docker-compose up -d Docker-compose up -d

2. 拔掉网关网线。

3. 往本地 1883 端口疯狂发送数据。

4. 5 分钟后插上网线。

5. 观察云端 EMQX，你会发现数据会以极快的速度“补传”上来，且时序数据库中的时间戳依然是数据产生时的时间（前提是 Payload 里带了时间戳，不要依赖数据库写入时间）。

四、 踩坑复盘 (Red Flags)

作为架构师，你必须预警以下风险：

1. 磁盘爆满风险

• 现象：断网时间过长（如超过 3 天），SQLite 缓存文件把网关仅有的 8GB 存储写满了，导致系统死机。

• 对策：必须在 nanomq.conf 中设置 disk_cache_size 限制（例如限制为 1GB）。并在网关层面配置 Watchdog（看门狗） 脚本，监控磁盘占用率。

2. 时间同步 (NTP) 问题

• 现象：网关断电重启后，如果没有 RTC 电池且没网，系统时间会重置到 1970 年。此时采集的数据时间戳是错的，补传到云端后全是脏数据。

• 对策：

• 硬件选型时，必须选择带 RTC 电池的工业网关。

• 在采集程序中增加逻辑：如果发现系统时间早于“2025年”，则拒绝采集或标记数据不可信。

3. 带宽风暴

• 现象：网络恢复瞬间，积压的 10 万条数据瞬间并发上传，占满 4G 带宽，导致正常的实时控制指令下不去。

• 对策：在 Bridge 配置中限制并发数（In-flight Window）。

五、 关联资源与选型

如果您的项目正面临类似的数据采集难题，以下资源可供参考：

• 硬件推荐：

• 本方案在 Moxa UC-8100 系列 和 研华 UNO-2271G 上验证通过。