8. 事件驱动与消息队列结合：消息队列作为事件通道、异步事件处理、事件持久化

说实话，很多做嵌入式开发的朋友，一开始接触事件驱动和消息队列时，总觉得这是两码事。一个在讲怎么响应外部刺激，一个在讲怎么传递数据块。但在我做了几个中型项目之后，越来越觉得——消息队列就是事件驱动的天然载体。

你想想看，事件是什么？事件就是「发生了某件事」这个信息。消息队列是什么？就是用来传递信息的管道。把事件包装成消息，扔进队列，消费者取出来处理——这不就是事件驱动最朴素的实现吗？

8.1 消息队列作为事件通道

我最早接触这个思路，是在做一个多传感器融合的项目。当时有温度、湿度、气压、加速度四个传感器，每个传感器采集频率不一样，处理优先级也不一样。如果用传统的轮询方式，主循环里要写一堆 if-else 判断哪个传感器该处理了，代码很快就变成一坨浆糊。

后来我换了个思路：每个传感器采集完数据，就生成一个「传感器数据就绪」事件，扔到消息队列里。主循环只管从队列里取事件，根据事件类型分发处理。代码结构一下子就清晰了。

这里我给出一个典型的事件结构体定义：

// 事件类型枚举
typedef enum {
    EVENT_TEMP_READY = 0x01,
    EVENT_HUMID_READY = 0x02,
    EVENT_PRESSURE_READY = 0x04,
    EVENT_ACCEL_READY = 0x08,
    EVENT_BUTTON_PRESSED = 0x10,
    EVENT_TIMER_EXPIRED = 0x20,
    EVENT_SYSTEM_ERROR = 0x40
} event_type_t;

// 事件消息结构
typedef struct {
    event_type_t type;      // 事件类型
    uint32_t timestamp;     // 事件发生时间戳
    uint16_t source_id;     // 事件源标识
    uint8_t data[64];       // 事件附带数据（变长）
    uint8_t data_len;       // 数据长度
} event_msg_t;

这个结构体里，type 字段是关键。我习惯用位掩码的方式定义事件类型，这样可以用一个变量同时表示多个事件状态。当然，实际项目中事件类型可能多达几十种，用枚举加位掩码的组合方式最灵活。

8.2 异步事件处理

事件驱动最大的好处是什么？异步处理。说白了就是：事件产生者不用等事件处理完。

我在项目中遇到过一个问题：某个传感器采集数据后，需要做复杂的滤波算法，耗时大约 50 毫秒。如果直接在中断里做，会严重影响其他中断响应。如果放在主循环里做，又会导致采集间隔不稳定。

解决方案就是异步事件处理。传感器中断只做一件事：把事件消息扔进队列，然后立即返回。主循环里的一个任务专门从队列取事件，做滤波处理。这样中断占用时间从 50 毫秒降到了不到 1 毫秒。

来看一个简单的异步事件处理框架：

// 事件分发器
void event_dispatcher(event_msg_t *msg) {
    switch (msg->type) {
        case EVENT_TEMP_READY:
            // 温度数据就绪，交给滤波模块
            temp_filter_process(msg->data, msg->data_len);
            break;
            
        case EVENT_BUTTON_PRESSED:
            // 按键事件，交给UI模块
            ui_handle_button(msg->data[0]);
            break;
            
        case EVENT_TIMER_EXPIRED:
            // 定时器到期，检查系统状态
            system_health_check();
            break;
            
        default:
            // 未知事件，记录日志
            log_error("Unknown event: 0x%x", msg->type);
            break;
    }
}

// 主循环
void main_loop(void) {
    event_msg_t msg;
    
    while (1) {
        // 从队列取事件，阻塞等待
        if (queue_receive(&msg, portMAX_DELAY) == pdPASS) {
            event_dispatcher(&msg);
        }
    }
}

这里有个细节要注意：queue_receive 的阻塞时间。我一般用 portMAX_DELAY，让任务在没有事件时休眠，不浪费 CPU。但如果你有多个优先级的事件，可能需要用非阻塞方式配合超时机制。

8.3 事件持久化

事件持久化，听起来高大上，其实说白了就是：把事件存起来，防止丢失。

为什么要持久化？我举个例子。在一个工业控制项目中，设备需要记录所有操作事件和异常事件，用于事后分析。如果设备突然断电，内存里的事件就全丢了。这时候就需要把事件写入非易失存储，比如 Flash 或 EEPROM。

事件持久化的设计要点：

考虑因素	说明	我的建议
存储介质	Flash、EEPROM、SD卡等	小数据用EEPROM，大数据用Flash
写入频率	频繁写入会磨损存储介质	使用环形缓冲区，批量写入
数据完整性	断电可能导致数据损坏	加CRC校验，双备份存储
读取速度	启动时需要恢复事件	索引表+数据块分离

我常用的做法是：在内存中维护一个事件日志缓冲区，当缓冲区满或者定时器触发时，批量写入 Flash。这样既减少了写入次数，又保证了事件不会丢失太多。

来看一个简化的事件持久化实现：

#define EVENT_LOG_SIZE   512   // 日志缓冲区大小（事件数）
#define FLASH_SECTOR_ADDR 0x08040000  // Flash存储地址

typedef struct {
    event_msg_t events[EVENT_LOG_SIZE];
    uint16_t write_index;   // 写入位置
    uint16_t read_index;    // 读取位置
    uint16_t count;         // 当前事件数
} event_log_t;

static event_log_t log_buffer;

// 写入事件到日志缓冲区
void event_log_write(event_msg_t *msg) {
    uint16_t next_index = (log_buffer.write_index + 1) % EVENT_LOG_SIZE;
    
    // 缓冲区满，触发持久化
    if (next_index == log_buffer.read_index) {
        event_log_flush();  // 批量写入Flash
    }
    
    memcpy(&log_buffer.events[log_buffer.write_index], msg, sizeof(event_msg_t));
    log_buffer.write_index = next_index;
    log_buffer.count++;
}

// 批量持久化到Flash
void event_log_flush(void) {
    uint32_t addr = FLASH_SECTOR_ADDR;
    uint16_t count = log_buffer.count;
    
    // 擦除Flash扇区
    flash_erase_sector(FLASH_SECTOR_ADDR);
    
    // 写入事件数据
    for (uint16_t i = 0; i < count; i++) {
        flash_write(addr, &log_buffer.events[i], sizeof(event_msg_t));
        addr += sizeof(event_msg_t);
    }
    
    // 重置缓冲区
    log_buffer.write_index = 0;
    log_buffer.read_index = 0;
    log_buffer.count = 0;
}

8.4 整体架构图

说了这么多，我把整个架构画成一张图，方便你理解：

从这张图可以看出，整个架构分为四个层次：事件源产生事件，消息队列作为通道传递事件，事件处理器异步处理事件，持久化模块保证事件不丢失。每个层次各司其职，耦合度很低。

8.5 实际项目中的经验总结

最后，我分享几个在实际项目中踩过的坑：

• 事件优先级问题：我曾经把所有事件都放在一个队列里，结果高优先级事件被低优先级事件堵住了。后来改用多队列方案，每个优先级一个队列，高优先级队列优先处理。
• 事件丢失问题：队列深度设置不合理，导致事件溢出。我的经验是：队列深度至少是最大事件产生速率的 2 倍，并且要有溢出告警机制。
• 持久化性能问题：一开始每个事件都直接写 Flash，结果系统响应变得很慢。改成批量写入后，性能提升了 10 倍以上。
• 事件重复处理：在异步处理中，同一个事件可能被多个消费者处理。我习惯在事件结构体里加一个 processed_flag 字段，处理完就标记一下。

事件驱动与消息队列的结合，说白了就是让系统变得更「聪明」——事件来了就处理，处理不完就排队，怕丢了就存起来。这种架构在嵌入式系统中越来越常见，尤其是那些需要处理多种外部事件、要求高可靠性的场景。

嗯，这一章的内容就到这里。记住：消息队列是骨架，事件是血液，异步处理是心跳，持久化是保险。把这四样东西用好，你的系统架构会变得非常健壮。

---

公众号:蓝海资料掘金营，微信deep3321