AWS EC2用Apache WSGI部署Flask后无法获取Celery任务状态更新怎么办

问题诱因 #

该问题确实是Celery RPC结果后端的固有设计限制导致的，核心原因有两点：

• RPC后端（rpc://）基于RabbitMQ临时队列实现，结果存储是一次性、仅可读取一次的：任务的状态、中间meta数据、最终结果都会推送到专属临时队列，内容被消费者读取一次后就会被删除，无持久化存储。本地开发环境是单进程单线程Flask服务，SSE流的轮询请求由同一个上下文持有结果引用，不会出现多请求竞争消费的问题，所以运行正常；而部署到Apache+WSGI环境后，默认是多进程/多线程处理模式，每次SSE循环中调用task.state或task.info查询状态时，都会触发一次对RPC结果队列的消费请求，第一次查询拿到PENDING状态后，后续的状态更新会被其他WSGI工作进程抢走消费，当前SSE流对应的进程自然拿不到更新的PROGRESS状态和meta数据，所以一直显示PENDING、task.info为None。
• RPC后端本身不支持中间状态持久化：只有任务最终的返回结果会被推送，update_state()推送的中间PROGRESS状态在RPC后端的实现中没有完善的持久化支持，即使没有多进程竞争，也大概率出现中间状态丢失的问题。你测试的r.get()能正常拿到结果，是因为get()是一次性阻塞读取完整的最终结果，刚好匹配RPC后端的一次性消费特性。

修复方案 #

切换为支持持久化、可重复读取的结果后端是唯一稳定的解决方案：

• 优先选择Redis作为结果后端，配置简单、查询性能高，天然支持多次重复读取任务状态和中间meta数据，完全适配SSE流轮询查询进度的场景，你已经实际验证过该方案可行。
• 也可以选择MySQL、PostgreSQL等数据库作为结果后端，适合需要持久化存储历史任务状态的场景，缺点是查询性能低于Redis。
• 不要在生产环境使用RPC后端实现需要轮询中间状态的需求，其设计本身不支持该类场景。

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