我通常不需要在 Django 应用程序级编程（即视图）中显式使用线程。但我注意到一个看起来很有趣的库，它通过线程处理服务器端分析。
在 Django 视图中，您将使用他们的 Python 客户端在单独的（非守护进程）线程中将 HTTP POST 批量发送到他们的 Web 服务。通常，我会使用 RabbitMQ 来代替线程，但他们希望降低库的启动成本。
我的问题是，这种方法有什么缺点吗？线程有一些额外的内存占用，但我不太担心这一点。这显然取决于启动的请求/线程的数量。
线程不是守护进程并且可能长时间运行是一个问题吗？我假设 Gunicorn 进程是执行的主线程，并且它在无限循环中运行，因此它是否必须等待非守护线程退出通常并不重要。那是对的吗？
这是一个悬而未决的问题，但要点是了解 Django/Gunicorn 应用程序中非守护线程的影响。
Gunicorn 使用预分叉工人模型。 Master 进程生成并管理 Worker 进程。对于非 Tornado 用途，有两种 Worker：Sync http://docs.gunicorn.org/en/latest/design.html#sync-workers（默认）和Async http://docs.gunicorn.org/en/latest/design.html#async-workers.
在正常操作中，这些 Worker 循环运行，直到 Master 告诉它们正常关闭或杀死它们。 Workers 会定期向 Master 发出心跳，表明自己还活着并且正在工作。如果有心跳timeout http://docs.gunicorn.org/en/latest/configure.html#timeout发生，那么Master会杀死Worker并重新启动它。
因此，不干扰 Worker 主循环的守护线程和非守护线程应该不会产生影响。如果线程确实干扰了 Worker 的主循环，例如线程正在执行工作并将结果提供给 HTTP 响应的场景，那么请考虑使用异步 Worker。异步 Workers 允许 TCP 连接长时间保持活动状态，同时仍允许 Worker 向 Master 发出心跳。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
