3. 消息队列原理：队列模型、FIFO与优先级队列、队列深度与延迟的关系

消息队列这东西，说白了就是系统里的一根「水管」。数据从一头流进去，再从另一头流出来。但你别小看这根水管——它怎么设计，直接决定了你的系统会不会「堵死」。

我在做感知联调的时候，遇到过好几次因为队列设计不合理导致的丢帧问题。嗯，今天咱们就把这块掰开揉碎了讲清楚。

3.1 队列模型：先进先出（FIFO）

FIFO 是最基础的队列模型。数据按到达顺序排队，先来的先走。这就像你去食堂打饭，排在前面的先打到菜。

在嵌入式系统里，FIFO 的实现通常是一个环形缓冲区。我习惯用两个指针来管理：一个写指针，一个读指针。写指针追着读指针跑，读指针追着写指针跑。

// 一个简单的 FIFO 实现（环形缓冲区）
#define QUEUE_SIZE 256

typedef struct {
    uint8_t buffer[QUEUE_SIZE];
    volatile uint16_t head;  // 写指针
    volatile uint16_t tail;  // 读指针
} fifo_t;

// 入队
int fifo_push(fifo_t *q, uint8_t data) {
    uint16_t next = (q->head + 1) % QUEUE_SIZE;
    if (next == q->tail) {
        return -1;  // 队列满了
    }
    q->buffer[q->head] = data;
    q->head = next;
    return 0;
}

// 出队
int fifo_pop(fifo_t *q, uint8_t *data) {
    if (q->head == q->tail) {
        return -1;  // 队列空了
    }
    *data = q->buffer[q->tail];
    q->tail = (q->tail + 1) % QUEUE_SIZE;
    return 0;
}

你想想看，这个模型简单吧？但简单不代表没坑。我曾经在一个项目中，把队列深度设成了 128，结果发现写指针和读指针的差值计算总是出错。后来一查，原来是环形缓冲区的「满」和「空」状态判断搞混了。

注意：环形缓冲区判断满和空时，head == tail 表示空，但 head + 1 == tail 才表示满。如果你用 head == tail 表示满，那空和满就分不清了。这个坑我踩过，真的。

3.2 优先级队列：谁急谁先走

FIFO 虽然公平，但有时候不公平才是对的。比如在感知联调中，紧急的碰撞预警消息必须比普通的传感器数据先处理。这时候就需要优先级队列。

优先级队列的实现方式有很多种。我个人比较喜欢用「多级 FIFO」的方案——为每个优先级分配一个独立的 FIFO，然后按优先级从高到低轮询读取。

// 多级优先级队列示例
#define PRIORITY_LEVELS 4

typedef struct {
    fifo_t queues[PRIORITY_LEVELS];
} priority_queue_t;

// 按优先级入队
int priority_push(priority_queue_t *pq, uint8_t priority, uint8_t data) {
    if (priority >= PRIORITY_LEVELS) return -1;
    return fifo_push(&pq->queues[priority], data);
}

// 按优先级出队（高优先级优先）
int priority_pop(priority_queue_t *pq, uint8_t *data) {
    for (int i = 0; i < PRIORITY_LEVELS; i++) {
        if (fifo_pop(&pq->queues[i], data) == 0) {
            return i;  // 返回优先级等级
        }
    }
    return -1;  // 所有队列都空
}

这里有个问题——如果高优先级消息一直来，低优先级消息可能永远得不到处理。这叫「优先级反转」或者「饥饿」。我建议你在实际项目中加一个老化机制：如果一个消息在队列里待了太久，就自动提升它的优先级。

实战技巧：我在做自动驾驶感知模块时，把碰撞预警设为优先级 0，车道保持设为优先级 1，普通传感器数据设为优先级 2。这样紧急消息的延迟能控制在 1ms 以内。

3.3 队列深度与延迟的关系

队列深度，说白了就是队列能存多少条消息。这个值设大了，内存占用高；设小了，容易丢消息。那到底怎么选？

我一般用这个公式来估算：

队列深度 = 最大入队速率 × 最大允许延迟

举个例子：假设你的传感器每秒产生 1000 条消息，每条消息处理需要 5ms，那么队列深度至少需要：

1000 条/秒 × 0.005 秒 = 5 条

但实际项目中，我通常会留 2-3 倍的余量。因为突发流量是常态。

队列深度	延迟	丢包率	内存占用
16	低（<1ms）	高（突发时易丢）	小
64	中（1-5ms）	中	中
256	高（5-20ms）	低	大

你看这个表就明白了——深度和延迟是正相关的。队列越深，消息等得越久。但丢包率会降低。这是个 trade-off。

核心观点：队列深度不是越大越好。我见过有人把队列设成 1024，结果系统内存爆了，延迟飙到 100ms 以上。合适的深度，是在「不丢消息」和「延迟可接受」之间找到平衡点。

3.4 知识体系图

下面这张图，把消息队列的核心逻辑串起来了。你可以看到 FIFO、优先级队列、队列深度三者之间的关系。

这张图你看懂了吗？数据从左边进来，经过队列模型（FIFO 或优先级队列），再根据队列深度决定等待时间，最后被处理。延迟和丢包率是相互制约的——你不可能既要低延迟又要零丢包。

我的建议：在项目初期，先用默认深度跑起来，然后用示波器或者日志工具观察实际延迟。根据实测数据再调整深度。别一开始就追求完美，先跑通再说。

好了，消息队列的原理就讲到这里。记住一句话：队列是系统的缓冲，不是系统的瓶颈。设计得好，它能帮你扛住流量洪峰；设计得不好，它就是最大的延迟来源。

可可精品资料库

📚 课程目录

3. 消息队列原理：队列模型、FIFO与优先级队列、队列深度与延迟的关系

3.1 队列模型：先进先出（FIFO）

3.2 优先级队列：谁急谁先走

3.3 队列深度与延迟的关系

3.4 知识体系图