Countdown轮询+看门狗兜底

Mon, 13 Jul 2026 00:00:00 +0000

为什么需要轮询

异步任务最常见的场景是：提交一个耗时操作，然后等它完成。但有一种场景更棘手——你不知道要等多久。

比如：调用一个异步 API 提交工单，对方处理完回调通知你。优雅的做法是起个 Webhook 接口被动接收回调。但生产环境里回调可能丢失（对方没发、网络抖动、你的服务刚好重启），于是你还需要一个主动轮询的兜底机制。

轮询最粗暴的写法：

@app.task
def poll_task(task_id):
 # 轮询等结果，最多等 5 分钟
 deadline = time.time() + 300
 while time.time() < deadline:
 result = check_external_api(task_id)
 if result:
 handle_result(result)
 return
 time.sleep(10) # 阻塞 Worker 进程长达 5 分钟
 raise TimeoutError("轮询超时")

time.sleep(10) 会死死占住一个 Worker 进程。如果有 10 个这样的轮询任务同时跑，10 个 Worker 全部被堵死，其他正常任务全部排队等候——这就是经典的"轮询阻塞"。

Countdown 轮询：非阻塞重试

Celery 的 countdown 参数可以让任务延迟执行而不占用 Worker：

@app.task(bind=True, max_retries=30)
def poll_with_countdown(self, task_id, deadline=None):
 """countdown 轮询：每次检查后释放 Worker，10 秒后再来"""
 if deadline is None:
 deadline = time.time() + 300 # 默认等 5 分钟
 
 if time.time() > deadline:
 raise self.MaxRetriesExceededError(
 f"任务 {task_id} 轮询超时"
 )
 
 result = check_external_api(task_id)
 if result:
 handle_result(result)
 return # 完成
 
 # 未就绪，10 秒后重试，Worker 立即释放处理其他任务
 raise self.retry(countdown=10)

关键在于 self.retry(countdown=10)——它告诉 Broker：“这个任务 10 秒后再投递一次”，当前 Worker 立即释放去处理下一个任务。

设计模式 on giftiaのblog

Countdown轮询+看门狗兜底

为什么需要轮询

Countdown 轮询：非阻塞重试