worker_shutdown_timeout仅控制Worker自身等待任务完成的最长时间，不能强制Master清理“死连接”旧Worker；其真实残留源于子进程卡死、Broker队列未清理、result backend缓存过期等，需配合killasgroup、健康检查、Redis TTL等外部机制协同治理。
worker_shutdown_timeout 是 Celery 中用于控制 Worker 进程在接收到关闭信号后等待任务完成的最长时间。但它本身不能直接强制 Master（如 Celery Beat 或监控进程）清理“死连接”的旧 Worker——因为 Celery 的 Master 侧（比如 celery -A proj worker 启动的主 Worker 进程）并不主动维护“Worker 列表”，也没有中心化注册表；所谓“旧 Worker”残留，通常表现为：
• Broker（如 Redis/RabbitMQ）中仍有未确认的 task 消息或未被消费的队列
• Flower 或 celery inspect 显示已断连但状态未及时清除的 Worker 名称
• 系统进程里残留僵尸 Worker 子进程（尤其是使用 prefork pool 时）
理解“死连接” Worker 的真实来源
所谓“无法退出的旧 Worker”，多数不是因为 worker_shutdown_timeout 没生效，而是：
- Worker 主进程已退出，但子工作进程（child process）卡在长阻塞调用（如无超时的 HTTP 请求、数据库锁、无限循环）中，未响应 SIGTERM
- Broker 侧仍保留该 Worker 声明的队列（尤其是 auto-delete=false 的队列），导致
celery inspect active_queues仍显示它“存在” - 使用 Redis 作为 result backend 时，
celery inspect stats返回的pool信息可能缓存旧值，实际进程早已消失 - Celery Beat 或部署脚本误判 Worker 状态，反复尝试“重启”一个并不存在的 Worker 实例
正确使用 worker_shutdown_timeout 配合优雅退出
该参数作用于 Worker 自身，确保它在收到 SIGTERM 后最多等待指定秒数再强制终止子进程。要让它真正起效，需配合以下设置：
- 启动时显式指定：
celery -A proj worker --concurrency=4 --worker-shutdown-timeout=30 - 确保 Worker 使用支持中断的执行池（默认 prefork 可用，但需避免子进程陷入不可中断系统调用）
- 在任务代码中主动响应中断：对 requests、socket、time.sleep 等加 timeout，并捕获
KeyboardInterrupt或SystemExit - 不依赖
worker_shutdown_timeout来“通知 Master”，它只影响当前 Worker 进程自身生命周期
让 Master（调度/运维层）识别并清理“幽灵 Worker”
真正需要你干预的是外部管理逻辑。例如：
- 用
celery inspect ping定期探测存活 Worker，超时无响应则认为已死亡，从你的服务发现列表中移除 - 在 systemd / supervisor 配置中启用
KillMode=mixed（systemd）或killasgroup=true（supervisor），确保发送 SIGTERM 时一并终止所有子进程 - 对 Redis backend，可定期运行脚本清理过期的
celery-task-meta-*key（需配合result_expires） - 避免手动创建非 auto-delete 队列；若必须，用
celery amqp queue.delete或 broker 管理界面手动清理残留队列
替代方案：用健康检查 + 自动驱逐更可靠
比依赖超时参数更健壮的做法是引入外部健康机制：
- 为每个 Worker 启动时写入一个带 TTL 的 Redis key（如
worker:hostname:pid:heartbeat），任务内每 10 秒更新一次 - 独立守护进程扫描这些 key，超过 60 秒未更新即判定为死 Worker，触发
celery control cancel_consumer或直接redis-cli DEL相关队列绑定 - 结合容器编排（如 Kubernetes）时，用 liveness probe + preStop hook：先发
celery control shutdown，等待worker_shutdown_timeout，再发 SIGKILL
