4. 断网检测机制配置

断网缓存与补传能否真正生效，前提是网关必须"知道自己已经断网"。如果断网检测迟钝，数据会继续按在线模式发往云端，结果全部超时丢弃；如果检测过于敏感，一次短暂抖动就触发缓存切换，会造成频繁的状态翻转和补传风暴。因此，断网检测机制的核心不是"能不能发现断网"，而是"在什么条件下、以多快速度、用多大把握判定断网"。本节围绕链路探测方式、心跳与超时阈值、状态判定逻辑和防抖策略四件事展开配置实践。

一、链路探测方式的选择

矿山边缘网关通常同时存在多条链路：以工业以太网或矿用光纤连接井上机房、以 4G/5G 无线链路作为备份、部分场景还有专网或卫星回传。断网检测要针对"业务真正依赖的那条路径"设计探测，而不是简单 ping 一个公网地址。常见探测方式有三类：

• ICMP 探测：周期性 ping 云端接入网关或指定探测地址，实现简单、开销小，但部分运营商网络或云安全组会屏蔽 ICMP，导致"能通业务却 ping 不通"的误判。
• TCP 端口探测：向云端 MQTT/HTTPS 服务端口发起连接或半连接，能反映业务端口可达性，比 ICMP 更贴近真实业务，但需注意探测频率对服务端连接数的影响。
• 应用层心跳：由网关与云端在业务协议层（如 MQTT 的 PINGREQ/PINGRESP、自定义心跳报文）交互，最能反映"业务通道是否可用"，是判定断网的主依据。

工程上推荐"应用层心跳为主、TCP 探测为辅、ICMP 仅作参考"的组合方式：心跳决定业务可用性，TCP 探测用于区分"链路断"与"云端服务异常"，ICMP 只用于辅助定位。探测目标应选择与业务同路径、同区域的接入点，避免跨运营商绕行造成误判。

二、心跳周期与超时阈值的设定

心跳周期 T 与超时阈值 N 共同决定最坏情况下的断网发现时延：发现时延 ≈ T × N。例如心跳周期设为 10 s、连续 3 个周期无响应判定断网，则最坏发现时延约 30 s。这两个参数需要在"发现速度"和"误判概率"之间权衡：T 越小、N 越小，发现越快，但无线链路抖动、云端瞬时拥塞都可能触发误判；T 越大、N 越大，判定越稳，但断网期间产生的数据会更多依赖本地缓存，且补传压力集中。

结合矿山现场经验，可参考如下示例参数（属教学示例，需按现场链路质量实测调整）：

除心跳外，还应设置单次响应超时（如 3 s），即一次心跳发出后多久未收到响应记为一次失败。单次超时应小于心跳周期，否则失败计数会被下一次心跳覆盖。配置时建议将心跳周期、单次超时、失败次数三者写入网关配置文件并支持远程下发，便于按季节、按矿区网络状况调整。

三、断网状态判定逻辑

网关的链路状态不应只有"在线/离线"两态，建议设计为四态：在线（ONLINE）、疑似异常（SUSPECT）、离线（OFFLINE）、恢复确认（RECOVERING）。判定逻辑如下：

1. 在线状态下，每次心跳成功则失败计数清零；
2. 一次心跳失败，进入疑似异常，失败计数加 1，但业务仍按在线模式尝试发送；
3. 失败计数达到 N，判定为离线，立即切换至本地缓存写入模式，并记录断网时刻；
4. 离线期间持续探测，连续 M 次心跳成功（M 可与 N 不同，通常取 2～3）后进入恢复确认，先补传积压数据并校验，确认稳定后再回到在线状态。

这里的关键是"失败计数"和"成功计数"要分开维护，且离线判定与恢复判定使用不同的阈值，避免在临界点反复横跳。同时应记录每次状态切换的时间戳、失败原因（超时、连接拒绝、DNS 失败等），为后续排障提供依据。

四、防抖策略

矿山现场电磁干扰强、无线信号随罐笼升降和采掘面推进而波动，单纯"连续 N 次失败即断网"仍可能被短时抖动触发。常用防抖手段包括：

• 连续失败计数：最基础的防抖，要求失败必须连续发生，中间任何一次成功即清零；
• 状态保持时间（Hysteresis）：判定离线后设置最短保持时间（如 60 s），期间即使心跳恢复也不立即切回在线，防止"断—通—断"高频翻转；
• 多目标交叉验证：同时探测主接入点和备用接入点，仅当两者均不可达才判定断网，可排除单一目标故障造成的误判；
• 业务侧佐证：结合最近一次业务报文发送的成功率、RTT 突增等指标辅助判断，避免"心跳通但业务不通"的假在线。

五、配置实践与结果判读

下面给出一份网关断网检测的配置样例（YAML 形式，参数为教学示例）：

link_detection:
  primary:
    type: mqtt_heartbeat
    target: mqtts://cloud-gw.mine.local:8883
    interval_s: 10
    response_timeout_s: 3
    fail_threshold: 3
    recover_threshold: 2
  secondary:
    type: tcp_probe
    target: 10.20.30.40:8883
    interval_s: 15
    response_timeout_s: 3
  icmp_reference:
    target: 10.20.30.1
    interval_s: 30
  debounce:
    min_offline_hold_s: 60
    cross_check: true
  state_log:
    path: /var/log/gw/link_state.log
    keep_days: 30

配置完成后，可通过三种方式验证：其一，人为拔掉上行网线或关闭无线模块，观察状态日志中 ONLINE→SUSPECT→OFFLINE 的切换时间是否接近 T×N，并确认缓存写入是否在 OFFLINE 时刻启动；其二，制造 5～10 s 的短时丢包，验证是否只进入 SUSPECT 而未误判离线；其三，恢复链路后观察是否经过 recover_threshold 次成功心跳才回到 ONLINE，并检查补传是否按时间顺序进行。若发现切换过慢，优先检查单次响应超时是否设置过大；若发现频繁翻转，则调大 fail_threshold 或 min_offline_hold_s。

需要强调的是，断网检测的最终目的不是"尽快报离线"，而是让缓存与补传在正确的时刻启动、在正确的时刻结束。判定过晚，数据在发送队列中丢失；判定过早或恢复过快，则缓存与补传被反复触发。把探测方式、心跳阈值、状态机与防抖参数作为一个整体来配置，并用拔线、丢包、恢复三类测试去校准，才能得到既灵敏又稳定的断网检测行为。