工业级 Modbus 上位机架构：基于滴答引擎与状态锁的高并发调度器

文章目录

[工业级 Modbus 上位机架构：基于滴答引擎与状态锁的高并发调度器](#工业级 Modbus 上位机架构：基于滴答引擎与状态锁的高并发调度器)
- [❌ 直击痛点：传统"多定时器"与"请求队列"的灾难](#❌ 直击痛点：传统“多定时器”与“请求队列”的灾难)
- [✅ 核心架构：滴答引擎 (Tick Engine) + 防并发锁 (Busy Lock)](#✅ 核心架构：滴答引擎 (Tick Engine) + 防并发锁 (Busy Lock))
- - [1. 架构组件定义](#1. 架构组件定义)
  - [2. 单引擎滴答轮询 (Tick Engine)](#2. 单引擎滴答轮询 (Tick Engine))
  - [3. 闭环解锁与真实间隔 (Deadline Scheduling)](#3. 闭环解锁与真实间隔 (Deadline Scheduling))
- [🚀 进阶架构：如何优雅地融入"下发控制指令 (Write)"？](#🚀 进阶架构：如何优雅地融入“下发控制指令 (Write)”？)
- - 扩展方案：引入"写任务特权队列"
  - - [步骤 1：定义写任务结构和队列](#步骤 1：定义写任务结构和队列)
    - [步骤 2：开放给 UI 层的写接口](#步骤 2：开放给 UI 层的写接口)
    - [步骤 3：改造滴答引擎（核心优先级逻辑）](#步骤 3：改造滴答引擎（核心优先级逻辑）)
    - [步骤 4：写操作的回调解锁](#步骤 4：写操作的回调解锁)
- 结语：为什么这套架构被称为"工业级"？

工业级 Modbus 上位机架构：基于滴答引擎与状态锁的高并发调度器

在开发工控上位机（如与 PLC、传感器网络通信）时，最常见的需求是对多个节点进行不同周期的轮询读取。

❌ 直击痛点：传统"多定时器"与"请求队列"的灾难

很多初学者在处理多节点轮询时，通常会采用以下两种错误架构：

多定时器模式（Multi-Timers）：为每个传感器开一个独立的定时器（如 A节点500ms，B节点1000ms）。当时间重叠时，底层网络瞬间涌入大量并发请求，极易导致粘包、丢包或底层句柄崩溃。
定频请求队列（Queueing）：用一个定时器无脑把"读取任务"压入队列。如果下位机卡顿或断网，队列会在几秒内积压海量历史请求（请求雪崩）。网络恢复后，上位机疯狂向底层发送堆积的过期请求，直接把下位机"打死"。

核心结论：在周期性读取中，过期的历史数据毫无价值，坚决不能使用普通队列来积压读请求！

✅ 核心架构：滴答引擎 (Tick Engine) + 防并发锁 (Busy Lock)

为了实现真正的"失败安全（Fail-Safe）"和"自愈能力"，我们摒弃队列，采用"基于状态机的单引擎调度"。

1. 架构组件定义

我们需要在内存中维护两个极其轻量级的"账本"：

QHash<int, qint64> m_nextReadTimes：排班表。记录每个节点"下一次应该被读取的绝对时间戳"。
QSet<int> m_busyAddresses：防并发锁（出差名单）。记录当前已经发出请求、但还没收到响应的节点地址。

2. 单引擎滴答轮询 (Tick Engine)

全局只开启唯一一个高频定时器（例如 50ms）。这个定时器不负责发数据，只负责"查表"。

cpp 复制代码

// 伪代码：50ms 滴答引擎
connect(pollingTimer, &QTimer::timeout, this, [this](){
    qint64 now = QDateTime::currentMSecsSinceEpoch();

    for(const auto& item : m_config.items) {
        // 🛡️ 规则1：防并发锁。如果该节点还在等待响应，坚决跳过，绝不堆积请求！
        if (m_busyAddresses.contains(item.address)) continue;

        // ⏱️ 规则2：查排班表。找不到记录则默认为0（实现开机秒级冷启动）
        qint64 nextReadTime = m_nextReadTimes.value(item.address, 0);

        if (now >= nextReadTime) {
            // 条件满足，发车！
            m_busyAddresses.insert(item.address); // 🔒 上锁
            m_modbus->readRegisters(item.address, item.length); // 发送请求
        }
    }
});

3. 闭环解锁与真实间隔 (Deadline Scheduling)

数据的更新和时间的推算，必须在收到响应（或报错）之后进行。这保证了下位机永远能获得足额的休息时间，哪怕网络延迟极高，也不会被上位机疯狂催穿。

cpp 复制代码

// 接收到数据（或报错）的回调
connect(m_modbus, &ModbusTcpClient::dataReceived, this, [this](int startAddr, const QVector<uint16_t>& data){
    // 🔓 1. 第一时间解锁
    m_busyAddresses.remove(startAddr);

    for(const auto& item : m_config.items) {
        if (item.address == startAddr) {
            // 💡 2. 核心时刻：任务彻底结束了，才推算下一次任务的时间！
            qint64 now = QDateTime::currentMSecsSinceEpoch();
            m_nextReadTimes[item.address] = now + item.intervalMs;
            break;
        }
    }
    
    // 3. 执行数据解析与 UI 路由...
});

// 🚨 全局断网处理：清空所有锁，等待网络恢复后自动自愈
connect(m_modbus, &ModbusTcpClient::connectionError, this, [this](const QString &err){
    m_busyAddresses.clear(); 
});

🚀 进阶架构：如何优雅地融入"下发控制指令 (Write)"？

目前的架构完美解决了"读（Read）"的问题，因为读操作是周期性的，丢弃旧的读请求完全没问题。
但"写（Write）"操作（如用户点击"开启水泵"、"设定阈值"）具有两个根本不同的特性：

突发性与高优先级：用户点下按钮，必须第一时间响应，甚至要打断当前的读取轮询。
使命必达：写指令绝对不能被丢弃，必须排队执行。

扩展方案：引入"写任务特权队列"

为了兼容写操作，我们需要在原有架构上增加一个命令队列 ，并修改滴答引擎的优先级逻辑（写操作优先级永远大于读操作）。

步骤 1：定义写任务结构和队列

cpp 复制代码

// 在头文件中增加写指令队列
struct WriteTask {
    int address;
    uint16_t value;
};
QQueue<WriteTask> m_writeQueue; // 必须用队列，保证用户的多次点击都会被按顺序执行

步骤 2：开放给 UI 层的写接口

当用户在界面上操作时，直接把任务塞进队列，而不是直接操作底层。

cpp 复制代码

// 供 QML/UI 调用的写操作函数
void AppManager::writeRegister(int address, uint16_t value) {
    m_writeQueue.enqueue({address, value});
}

步骤 3：改造滴答引擎（核心优先级逻辑）

让滴答引擎每次"醒来"时，先看有没有紧急的写任务。如果有，暂停所有读任务，优先处理写任务。

cpp 复制代码

connect(pollingTimer, &QTimer::timeout, this, [this](){
    qint64 now = QDateTime::currentMSecsSinceEpoch();

    // 🚀 【新增逻辑】：最高优先级处理 Write 队列
    if (!m_writeQueue.isEmpty()) {
        // 如果当前总线忙（有没回来的读/写请求），暂时按兵不动，等总线空闲
        if (!m_busyAddresses.isEmpty()) return; 

        // 总线空闲，取出第一个写任务执行
        WriteTask task = m_writeQueue.dequeue();
        
        // 🔒 上锁（由于是单任务独占，我们可以用一个特殊的负数地址代表写锁，或者干脆锁住目标地址）
        m_busyAddresses.insert(task.address); 
        m_modbus->writeRegister(task.address, task.value);
        
        return; // 💡 极其关键：发完写请求直接return，不再执行下面的读操作！让出总线！
    }

    // ----------------------------------------------------
    // ⬇️ 下面是原本的"读轮询逻辑"（优先级较低，只有队列空了才会执行）
    
    for(const auto& item : m_config.items) {
        if (m_busyAddresses.contains(item.address)) continue;

        qint64 nextReadTime = m_nextReadTimes.value(item.address, 0);
        if (now >= nextReadTime) {
            m_busyAddresses.insert(item.address);
            m_modbus->readRegisters(item.address, item.length);
            
            // 为了防止一次发出太多读请求阻塞后面的写请求，
            // 工业界通常在这里加一个 break; 保证每个滴答只发一条指令。
            break; 
        }
    }
});

步骤 4：写操作的回调解锁

下位机完成写入并响应后，我们需要解锁，让被挂起的"读轮询"继续运转。

cpp 复制代码

connect(m_modbus, &ModbusTcpClient::writeCompleted, this, [this](int address){
    qInfo() << "地址" << address << "写入成功！";
    // 🔓 解锁总线，下一个滴答时，引擎会继续处理队列里的写任务，或者恢复读轮询
    m_busyAddresses.remove(address); 
});

结语：为什么这套架构被称为"工业级"？

这套架构将业务逻辑（定期读、突发写）与底层通讯（TCP/串口）彻底解耦：

防雪崩 ：通过 m_busyAddresses 锁机制，无论网络卡顿多久，内存中永远只有当前正在执行的任务，杜绝请求积压。
流量塑形 ：通过 m_nextReadTimes 在响应后计算下一次时间，严格保证下位机的处理间隙，保护单片机/PLC不被高频轮询打死。
绝对抢占 ：通过 m_writeQueue 配合 return 机制，写操作一旦产生，读操作瞬间静默让路，保证了控制指令的最低延迟。

掌握这种"状态机轮询 + 优先级调度"的思想，就掌握了复杂工控网关、游戏循环（Game Loop）以及设备驱动开发的最底层密码。