Airflow 2.0升级后pool插槽可用时任务仍卡在queued状态求助

根因定位 #

结合提供的版本、配置和日志信息，该问题属于Airflow 2.x早期版本+Celery 4.x组合的已知共性问题，核心根因如下：

• Celery 4.4.7 prefork工作池死锁bug：该版本Celery的prefork模式在高并发场景下，偶发子进程fork后的资源竞争，导致子进程直接挂死在airflow tasks run命令的初始化阶段，无法输出后续任务运行日志，也不会更新任务状态。
• Airflow 2.1.3 状态同步缺陷：该版本Celery Executor存在偶发的任务状态回写丢失问题，当MySQL元数据库写入压力较高时，任务状态无法从queued更新为running，前端显示卡住但实际进程可能已经异常退出。
• 结果后端配置不合理：使用MySQL作为Celery的result_backend，当结果回写时遇到数据库行锁、连接池耗尽等问题，会导致worker进程阻塞，无法推进任务流程。
• Redis broker 消息确认异常：redis 3.5.3 配合Celery 4.4.7时，偶发任务消息ack丢失，导致任务被标记为已接收但实际未被worker进程正常处理。

解决方案 #

临时应急方案 #

故障发生时无需重启全集群，可快速恢复业务：

• 执行命令airflow tasks clear -s <任务执行日期> <对应DAG名称> <卡住的任务名称>，强制清理卡住的任务实例，清理后任务会自动重新调度执行。
• 若清理后任务仍然卡住，重启对应Celery worker节点的进程，释放挂死的prefork子进程资源即可。

永久修复方案 #

1. 依赖版本升级
   • 升级Celery到5.2.7版本，该版本已完全修复prefork池死锁问题，同步将redis Python客户端升级到4.3.4版本。
   • 升级Airflow到2.2.5及以上稳定版本，修复任务状态同步的已知缺陷。
2. 配置优化
   • 将celery.result_backend从MySQL切换为Redis，减少数据库写入压力，避免结果回写阻塞。
   • 调整Celery worker工作模式，从prefork改为gevent，降低进程fork带来的资源开销和死锁概率：启动worker时添加--pool gevent参数，提前安装gevent依赖pip install gevent==21.12.0。
   • 新增配置celery.task_acks_late = True，开启任务迟到确认，确保worker只有在任务执行完成后才会删除broker中的消息，避免消息丢失。
3. 运维监控优化
   • 配置任务状态监控，当任务处于queued状态超过30分钟时自动告警，触发自动清理动作。
   • 监控Celery worker子进程状态，当出现子进程CPU/内存长期无波动、处于空闲挂死状态时，自动重启对应worker进程。

内容的提问来源于stack exchange，提问作者Pankaj Singh