FastAPI + Celery 实战：异步任务里调用 Redis 和数据库的全解析，及生产级组织方案

前面的文章里使用的BackgroundTasks进行的任务调用，这里使用Celery对整个方案重新构建下，核心逻辑同理！！！

Celery 的任务是在独立的工作进程（worker）中执行的，和 FastAPI 的请求进程是分离的。如果你在 API 路由里通过依赖项注入创建了一个数据库会话，然后把这个会话对象作为参数传给 Celery 任务，会发生什么？
首先，数据库会话（比如 SQLAlchemy 的 Session）通常不是可序列化的，根本传不到 worker 那边。就算你用了某些技巧把它序列化了，worker 那边拿到后，这个会话对应的底层数据库连接可能早已在原始进程中关闭，或者根本不存在。结果就是各种稀奇古怪的报错。
Redis 连接同理，如果你把连接池里“借”出来的连接直接传给 Celery 任务，序列化后到了 worker 端，完全无法使用。
我们需要在 Celery 任务函数内部，重新创建所需的资源（比如新的数据库 Session，新的 Redis 连接），并在任务执行完毕后，确保这些资源被正确关闭或归还。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

新版吗？好像是停更了吧。