python - 在 Django/Gunicorn 应用程序中拥有持久(非守护进程)线程的危险？

Question

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

在 Django View 中，您将使用他们的 Python 客户端在单独的(非守护进程)线程中将 HTTP POST 批处理到他们的 Web 服务。通常，我会使用 RabbitMQ 来做这样的事情，而不是线程，但他们想降低库的启动成本。

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

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

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

Answer 1

Gunicorn 使用预 fork worker 模型。 Master 进程生成并管理 Worker 进程。对于非 Tornado 用途，有两种 Worker:Sync (默认)和 Async .

在正常操作中，这些 Worker 循环运行，直到 Master 告诉它们正常关闭或杀死它们。 Worker 会周期性地向 Master 发出心跳，表示自己还活着，还在工作。如果心跳timeout发生，Master会杀掉Worker并重启。

因此，不干扰Worker主循环的daemon和non-daemon线程应该没有影响。如果线程确实干扰了 Worker 的主循环，比如线程正在执行工作并将结果提供给 HTTP Response 的场景，那么可以考虑使用 Async Worker。 Async Workers 允许 TCP 连接长时间保持事件状态，同时仍然允许 Worker 向 Master 发出心跳。