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

在Django视图中,您将使用他们的Python客户端在单独的(非守护程序)线程中将HTTP POST批量处理到其Web服务.通常情况下,我会选择RabbitMQ而不是线程,但他们希望降低库的启动成本.

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

事实上线程不是守护进程并且可能长期存在问题吗？我假设Gunicorn进程是执行的主线程并且它在无限循环中运行,因此通常无论是否必须等待非守护进程线程退出.那是对的吗？

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

解决方法:

Gunicorn使用前叉工人模型.主进程生成并管理工作进程.对于非Tornado用途,有两种Worker：Sync(默认)和Async.

在正常操作中,这些Worker会循环运行,直到Master告诉他们正常关闭或杀死它们.工人将定期向主人发出心跳,表明他们仍然活着并且正在工作.如果发生心跳timeout,则Master将终止该Worker并重新启动它.

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