在 Django/Gunicorn 应用程序中拥有持久（非守护程序）线程有危险吗？

Question

我通常不需要在我的 Django 应用程序级编程（即视图）中显式使用线程。但我注意到一个看起来很有趣的库，它通过线程处理服务器端分析。

在 Django 视图期间，您将使用他们的 Python 客户端在一个单独的（非守护程序）线程中将 HTTP POST 批量发送到他们的 Web 服务。通常情况下，我会使用 RabbitMQ，而不是线程，但他们希望降低库的启动成本。

我的问题是，这种方法有什么缺点吗？线程有一些额外的内存占用，但我不太担心。这显然取决于启动的请求/线程数。

线程不是守护进程并且可能长时间运行的问题是否存在？我假设 Gunicorn 进程是执行的主线程，并且它在无限循环中运行，因此它是否必须等待非守护线程退出通常并不重要。对吗？

这是一个悬而未决的问题，但重点是了解非守护线程在 Django/Gunicorn 应用程序中的影响。

Answer 1

Gunicorn 使用 pre-fork worker 模型。 Master 进程产生并管理 Worker 进程。对于非 Tornado 用途，有两种 Worker：Sync（默认）和Async。

在正常操作中，这些 Worker 循环运行，直到 Master 告诉它们正常关闭或杀死它们。 Worker 会定期向 Master 发出心跳，以表明他们仍然活着并且正在工作。如果出现心跳timeout，则Master会kill掉Worker并重启。

因此，不干扰 Worker 主循环的守护线程和非守护线程应该没有影响。如果线程确实干扰了 Worker 的主循环，例如线程正在执行工作并将结果提供给 HTTP 响应的场景，那么请考虑使用 Async Worker。 Async Worker 允许 TCP 连接长时间保持活动状态，同时仍允许 Worker 向 Master 发出心跳。