样章-第09讲-上报节拍与采集节拍1比1匹配的设计

第 9 讲 | 上报节拍与采集节拍 1:1 匹配的设计

【本讲要点】第 7 讲找到的根因，本质是一个"生产-消费速率不匹配"问题。这一讲把它抽象成通用模型，并给出三种背压策略。

一、先把问题抽象出来

第 7 讲的现象是：采集 1.2 秒一次，上报却慢 3 倍。当时我们把它归因为"状态机推进挂错了事件源"。

但如果把视角抬高一层，这是一类通用问题：

生产者（采集）和消费者（发送）的速率不匹配。

这类问题在嵌入式里无处不在：

只要两者速率不同，就会出现三种后果之一：丢数据、堆积、或者拖慢对方。

二、三种速率关系

设采集速率为 Rp（每秒产生多少帧），发送速率为 Rc（每秒能发多少帧）：

情况 1：Rp = Rc（理想，1:1）

采集:  ▼     ▼     ▼     ▼
发送:  ▼     ▼     ▼     ▼

这是最好的情况，但现实中几乎不存在——网络速率是波动的。

情况 2：Rp > Rc（生产快于消费）

采集:  ▼  ▼  ▼  ▼  ▼  ▼  ▼  ▼
发送:  ▼     ▼     ▼     ▼
       └──── 积压 ────┘

后果：缓冲区越积越多，最终溢出丢数据。 第 7 讲就是这个情况——采集 1.2s/帧，实际发送能力远低于此。

情况 3：Rp < Rc（生产慢于消费）

采集:  ▼        ▼        ▼
发送:  ▼        ▼        ▼
      └── 空闲 ──┘

后果：发送通道大量空闲，浪费带宽。 这个相对无害，但也说明你的采集频率可以更高。

三、解耦：让生产者不等消费者

第一原则：生产者和消费者必须是两个独立的任务，中间用队列连接。

/* 采集任务：只管产生数据，不关心能不能发出去 */
void sample_task(void *arg)
{
    for (;;) {
        vTaskDelay(pdMS_TO_TICKS(1200));       /* 稳定的 1.2s 节拍 */

        uint8_t *blk = mem_pool_alloc(s_pool);
        if (blk == NULL) {
            stat_inc(STAT_SAMPLE_DROP);        /* 池满 → 丢帧记账 */
            continue;
        }

        uint16_t len = sensor_pack(blk);
        frame_msg_t msg = { blk, len };

        if (xQueueSend(s_queue, &msg, 0) != pdPASS) {
            mem_pool_free(s_pool, blk);        /* 队满 → 归还并记账 */
            stat_inc(STAT_QUEUE_DROP);
        }
    }
}

/* 发送任务：只管把队列里的数据发出去，不关心多久采一次 */
void publish_task(void *arg)
{
    frame_msg_t msg;
    for (;;) {
        if (xQueueReceive(s_queue, &msg, portMAX_DELAY) == pdPASS) {
            iot_publish(msg.data, msg.len);    /* 阻塞式发送，但只阻塞自己 */
            mem_pool_free(s_pool, msg.data);
        }
    }
}

关键点：

• 采集任务永远不会被网络阻塞——它只管往队列里放，放不进去就丢帧记账；
• 发送任务永远不会被采集节拍拖累——队列里有就发，没有就等；
• 两者的速率彻底解耦。

这就是第 7 讲的修复方案上升到架构层面的表述。

四、背压策略：队列满了怎么办

解耦之后，新问题出现了：队列/内存池满了，生产者该怎么办？

注意：绝对不能"阻塞等待"。 一旦采集任务阻塞在"等空闲块"上，它就丧失了实时性，传感器数据会丢在更底层。

三种工程策略：

策略 1：丢最新的（Drop newest）—— 最简单

if (xQueueSend(s_queue, &msg, 0) != pdPASS) {
    mem_pool_free(s_pool, blk);       /* 丢弃这一帧 */
    stat_inc(STAT_QUEUE_DROP);
}

• 优点：生产者不阻塞，实时性最好；
• 缺点：丢的是最新数据；
• 适用：传感器数据"旧的不如新的重要"，且丢几帧可接受。

策略 2：丢最旧的（Drop oldest）—— 保证最新数据能进

if (xQueueSend(s_queue, &msg, 0) != pdPASS) {
    frame_msg_t old;
    xQueueReceive(s_queue, &old, 0);      /* 挤掉最旧的一帧 */
    mem_pool_free(s_pool, old.data);
    xQueueSend(s_queue, &msg, 0);
    stat_inc(STAT_QUEUE_OVERWRITE);
}

• 优点：总能保留最新的数据；
• 缺点：队列操作多一步，且丢的是"更完整的旧数据"；
• 适用：状态类数据（温湿度、位置），最新值最重要。

策略 3：降采样（Decimation）—— 主动降低生产速率

/* 当队列水位超过 70% 时，主动把采集周期拉长 */
uint32_t period = pdMS_TO_TICKS(1200);
if (queue_water_level() > 70) {
    period = pdMS_TO_TICKS(2400);         /* 降采样到一半 */
    stat_inc(STAT_DECIMATE);
}
vTaskDelay(period);

• 优点：从源头减少压力，避免无限积压；
• 缺点：改变采集节奏，可能丢失瞬态；
• 适用：周期性监测类数据（不只是"最新的重要"，"均匀采样"也重要）。

三种策略对照

五、如何做到"真正的 1:1"

丢帧只是"优雅地失败"。要做到不丢帧，必须让 Rc ≥ Rp。

方法 1：提高消费速率（最有效）

第 7 讲用的就是这个方法：把状态推进从"数据到达"改为"ACK 到达"，让 Rc 从 0.83 帧/s 提升到 3.3 帧/s。

排查公式：

Rp = 1 / 采集周期
Rc = 1 / (单包耗时 × 包数)

只要 Rc < Rp，就一定会积压。要么降 Rp，要么提 Rc。

方法 2：批量打包（Batch）

把多帧合并成一次上报，把"每帧一次通信往返"变成"多帧一次往返"：

/* 攒够 4 帧再发，减少 75% 的通信开销 */
if (batch_count >= 4 || batch_timeout) {
    iot_publish_batch(batch, batch_count);
}

代价：上报延迟增加。适用于"可以攒一批"的场景。

方法 3：令牌桶限流（生产者主动限速）

/* 令牌桶：每秒最多产生 2 帧 */
static uint32_t tokens = 0;
static uint32_t last_refill = 0;

bool can_produce(void)
{
    uint32_t now = xTaskGetTickCount();
    uint32_t elapsed = now - last_refill;
    tokens = (tokens + elapsed * RATE / 1000 > BUCKET_SIZE)
             ? BUCKET_SIZE : tokens + elapsed * RATE / 1000;
    last_refill = now;
    if (tokens > 0) { tokens--; return true; }
    return false;
}

这是"从源头保证不超发"，比事后丢帧更优雅。

六、必须做的两件事：统计与告警

没有统计的节拍匹配，等于闭着眼睛开车。

typedef struct {
    uint32_t sample_total;     /* 总采集帧数 */
    uint32_t publish_total;    /* 总发送帧数 */
    uint32_t sample_drop;      /* 池满丢弃 */
    uint32_t queue_drop;       /* 队满丢弃 */
    uint32_t queue_max_depth;  /* 队列历史最大深度 */
} rate_stat_t;

四个关键指标：

1. sample_total vs publish_total：如果长期不相等，说明在持续丢帧；
2. queue_max_depth：队列深度持续增长 = 速率不匹配的铁证；
3. 两个 drop 计数：区分"池满"还是"队满"，定位瓶颈在内存还是队列；
4. 上报成功率：publish_total / (publish_total + 重传次数)。

在现场设备上，这些数字能让你不连调试器就判断出问题。

log_info("rate: sample=%u pub=%u drop=%u/%u qmax=%u",
         st.sample_total, st.publish_total,
         st.sample_drop, st.queue_drop, st.queue_max_depth);

七、小结

四句话：

1. 采集与上报的速率不匹配是通用问题，本质是"生产者快于消费者"。
2. 第一原则是解耦：两个独立任务 + 队列，生产者绝不阻塞。
3. 队列满时用背压策略（丢最新/丢最旧/降采样），绝不阻塞等待。
4. 想真正 1:1，只有两条路：提高消费速率（改事件源）或降低生产速率（降采样/批量）。

下一讲（第 10 讲），我们处理所有 IoT 工程师最头疼的一类问题：设备卡机。我会用一个真实的"紧急按键导致卡机"案例，讲透看门狗设计、HardFault 现场还原和复位原因判断。

欢迎点赞收藏加关注，解锁更多专栏内容