HAProxy核心机制中stick-table过期任务队列的竞态条件分析与修复

在HAProxy的高并发场景下，一个隐藏的竞态条件可能导致进程异常终止。本文将深入分析这个涉及stick-table过期任务调度的核心机制问题，以及其解决方案。

问题现象

在高负载环境（70-80Gbps流量）下，HAProxy会出现进程崩溃。核心转储显示崩溃发生在任务队列处理函数中，触发了BUG_ON(task->expire == TICK_ETERNITY)断言。这表明系统试图将一个无限期有效的任务加入执行队列，违反了任务调度的基本前提。

技术背景

HAProxy的stick-table功能用于跟踪客户端状态，每个表都有一个关联的过期任务负责清理过期条目。当表条目被访问时，系统会通过stktable_touch_*系列函数更新其过期时间，并可能重新调度过期任务。

根本原因分析

问题的核心在于stktable_requeue_exp()函数中的锁保护范围不足。原始实现中：

1. 函数先获取表锁计算新的过期时间
2. 释放表锁
3. 然后调用task_queue()将任务加入队列

这种设计存在一个时间窗口：在锁释放后、任务入队前，如果过期任务恰好执行，可能导致任务状态不一致。具体来说，过期任务可能将task->expire重置为TICK_ETERNITY，而后续的task_queue()调用会触发断言。

解决方案

修复方案简单而有效：扩大锁的保护范围，确保任务入队操作也在锁的保护下进行。具体修改是将HA_RWLOCK_WRUNLOCK调用移到task_queue()之后：

void stktable_requeue_exp(struct stktable *t, const struct stksess *ts)
{
    // 计算新过期时间...
    task_queue(t->exp_task);
    HA_RWLOCK_WRUNLOCK(STK_TABLE_LOCK, &t->lock);
}

这种修改确保了：

1. 过期任务执行与任务入队操作的完全串行化
2. 消除了状态不一致的时间窗口
3. 保持了原有的功能逻辑不变

生产环境验证

该修复在真实生产环境中经受了严格验证：

1. 初始测试显示系统稳定性显著提升
2. 后续发现的异常崩溃经查与stick-table分片功能不兼容有关，非本修复引入
3. 在修正配置后，系统保持长期稳定运行

技术启示

这个案例展示了几个重要的系统编程经验：

1. 锁的作用域设计需要仔细考虑所有可能的竞态路径
2. 高并发场景会显著放大竞态条件的出现概率
3. 断言(assert)是发现深层逻辑错误的重要工具
4. 生产环境验证是检验修复有效性的最终标准

该修复已被合并到HAProxy主线，有效解决了这一核心机制中的竞态问题。对于使用stick-table功能的高负载HAProxy部署，建议尽快应用此修复以获得更好的稳定性。