【发布时间】：2013-04-30 16:08:16
【问题描述】：
我对 Python 比较陌生，来自 .Net 背景。
简短版：如何创建应用程序范围的单例或其他机制以允许多个线程/进程相互通信？
也许我被宠坏了，但在 .Net 中，我只会在 App_Start 或“应用程序级别”的其他东西中创建一些东西。我怎样才能在 python/uwsgi 中做同样的事情？
长版：
我们有一个使用 Django 编写的 Restful API。
一些调用需要一些预处理，然后传递到执行长时间运行操作的后端系统。
目前的流程看起来像......
- 接收处理所有符合给定条件的文档的请求
- Api 确定哪些文档符合这些标准（大约 100,000 - 需要 15-20 秒）
- Api 为这个批处理请求生成一个 uuid
- Api 将消息发布到每个文档的后端队列，并引用批次 ID。
- Api 在不同的队列中侦听“已完成”消息并计算每个批次 ID 的成功/失败次数（约 1-15 分钟）
- 在处理过程中，UI 可以请求更新特定批次 ID
我们需要使用与服务页面不同的线程来监听响应队列，因为它位于wait spin-loop...
while True:
self.channel.wait()
我通过引用 QueueManager 这是一个单例来处理这个问题。管理器触发初始请求，记录批处理 ID，然后在第二个线程中监控队列并更新本地状态。
我们实际上并不关心长期保持状态 - 如果消息在队列中，则处理将由后端完成，状态监控只是向用户提示事情正在进行中.如果他们浏览离开，他们也会失去对状态的访问权限（批次 id 存储在 JS 的内存中）
这有几个好处 - 我们避免使用数据库来同步信息（以及相关的清理）。我们能够使用单个线程作为消息消费者，并且不必担心并发问题，因为只有一个线程会收集消息/更新本地状态。
所以...现在是时候使用 uwsgi 运行它了。我发现了一个主要问题。如果我将进程数设置为 1，则单例会按预期工作，但在 api 处理数据的 15-20 秒期间，所有请求都会被阻止。显然这是不可接受的。相反，如果我启动多个工作人员，每个工作人员都有自己的单例和自己的消息侦听器 - 所以如果发布者和消费者是同一个进程，这几乎是随机的。即使是这样，状态更新请求也可能不会在同一个过程中结束。
如何在多个工作人员之间交换状态信息？有没有办法使用多个线程而不是多个工作人员？
看来我真的需要：
- n 个线程，每个服务请求
- 1 个线程监听队列
- 它们之间的某种内存通信方式
注意我已经得到了--enable-threads，但这似乎只适用于我生成的新线程（不知道为什么默认情况下不会启用）
【问题讨论】：
-
找到解决方案了吗？
-
@Will 不幸的是，文档很糟糕。似乎有一个 uwsgi 管理进程可以根据需要重新启动 uwsgi 进程。我们想要 1 个进程多线程而不是 1 个线程的多个进程。无论如何，我们最终离开了 uwsgi，所以我从来没有解决过这个问题。祝你好运
标签： python django multithreading ipc uwsgi