1.Django ORM 连接

gunicorn和celery

• Gunicorn worker 是 处理 Web 请求的短生命周期模型：

每个请求只执行一次 ORM 操作，通常持续几百毫秒到几秒
请求完成 → Django ORM 自动在 django.db.close_old_connections() 里关闭/回收连接
下次请求来时，再重新获取一个可用连接

👉 所以 不会出现连接闲置几小时的问题。
Gunicorn 自带的 middleware 流程已经帮你调用了 close_old_connections。

• Celery 在 每个任务执行前后 会调用 Django 的数据库管理钩子：
  close_old_connections()

如果一个任务执行过程中连接断开，ORM 也会触发自动重连机制

👉 所以 Celery 虽然长期运行，但它在任务级别做了连接管理，避免了闲置连接断开。

独立脚本

如果脚本启动后，一直 while True 保持运行，但中间可能几小时都没写数据库，那这条连接就会被数据库服务器超时回收。这样下次再使用ORM时，因为默认旧连接还在，会报错
django.db.utils.OperationalError: (2006, 'MySQL server has gone away')
所以需要 手动调用 close_old_connections() 来模拟 Gunicorn/Celery 的行为。

2.使用celery时使用redis做输入队列，redis连接问题

发送任务的时候，celery_task.delay(…) 本质就是：
1.建立到 Redis 的连接
2.用 LPUSH / XADD 把任务序列化写进去
redis连接是通过 kombu 来管理的
它会维护一个 连接池，不是每次都新建；一旦连接失效，kombu 下次使用时会抛异常并 自动重连。
所以不需要考虑连celery的redis连接问题。