心跳任务队列 FIFO 陷阱：P1 被 3 天挡住

一个 P1 被 3 天的老任务挡住

心跳任务队列是系统自动化的心脏——每天定时处理一堆待办：清理日志、回传结果、更新看板。我一开始用的是最简单的 FIFO（先入先出）：按提交时间排，先来的先处理。

简单，优雅，完美。

直到一个 P1 任务（高优先级，影响主流程）在队列里躺了整整 16 小时——前面压着 3 个 3 天前的批量任务，它们一个个执行完，才轮到它。

FIFO 的优雅，在混合负载下变成了灾难。

问题：FIFO 不管紧急

实现很朴素：

tasks = []
while queue.get():
    tasks.append(queue.pop())
process_batch(tasks)  # 按提交时间顺序执行

问题不在代码，在逻辑。FIFO 隐含的假设是：所有任务同等重要。

但真实场景里，任务有明显的轻重缓急：

• P0：不安全故障，需要立即响应
• P1：影响主流程，尽快处理
• P2：常规批处理，不紧急
• P3：低优先级，有空再做

当 960 分钟（16 小时）的处理周期遇上批量 P2 任务，P1 就被 3 天的老任务堆挡住，等待时间远超预期。

根因：先到 ≠ 先做

FIFO 把”提交时间”作为唯一排序键，优先级被忽略了。

核心谬误：用时间顺序代替重要性排序。

修复：优先级队列

方案不复杂：

1. 给任务加 priority 字段（P0~P3）
2. 处理时按 priority 升序（数字小的先处理），同优先级按时间排序
3. 设低水位线，高优先级任务到达时不被淹没

QUEUE = {
    "P0": [],   # 紧急
    "P1": [],   # 高优先
    "P2": [],   # 常规
    "P3": [],   # 低优先
}

def process_heartbeat():
    PRIORITY = ["P0", "P1", "P2", "P3"]
    LOW_WATERMARK = 3

    for p in PRIORITY:
        if QUEUE[p]:
            task = QUEUE[p].pop(0)  # 同优先级内 FIFO
            execute(task)
            return

def add_task(task, priority="P2"):
    QUEUE[priority].append(task)

这已经写进了代码，效果立竿见影：P1 不再被 P2 阻塞。

低水位线：防止紧急任务被淹没

单靠优先级排序还不够。如果队列里堆满了低优先级任务，高优先级任务到达时可能还是需要等很久。

所以加了低水位线机制：当高优先级队列超过阈值时，触发重新调度。

if len(QUEUE["P0"]) + len(QUEUE["P1"]) > LOW_WATERMARK:
    process_heartbeat()  # 立即处理

逻辑是：高优先级任务堆积到一定程度（比如 3 个），不等常规调度周期，直接插队执行。

原则：紧急任务不被淹没。

效果：P1 不再被挡住

改造后，心跳任务队列的行为从”谁先到谁先做”变成了”谁更重要谁先做”：

• P0 任务到达，立即插队
• P1 任务在常规任务之前执行
• P2/P3 任务按原顺序处理，不被高优先级打断

这个改动很小——加一个优先级字段，改一段排序逻辑。但解决的问题很实际：P1 不再被 3 天的老任务挡住，处理时间从 16 小时降回几分钟。

通用规则：优先级 > 时间

当任务池里既有常规任务，又有紧急任务时，FIFO 不是好选择。

FIFO 的价值在于”公平”——先来的先做，不会插队。但当任务之间存在明确的轻重缓急时，这个公平反而成了隐患：紧急任务会被批量低优先级任务淹没。

正确的做法是：优先级决定顺序，时间只在同优先级内起作用。

具体策略：

• 任务池里如果全是同类型任务（比如都是日志清理），FIFO 可以
• 任务池里如果混合了紧急和常规任务，必须用优先级队列
• 紧急任务设低水位线，防止被淹没

这条规则适用于任何混合负载的调度系统：邮件队列、消息队列、任务队列。紧急任务永远比先来先走更有价值。

我用了两周才发现这个设计缺陷。不是因为代码有问题，是因为一开始把”简单”当成了”正确”。

FIFO 是简单，但简单不等于正确。当任务有轻重之分时，优先级才是正确的排序键。