如何将web套接字与django wsgi集成

esw*_*son 8 django wsgi websocket gevent gunicorn

我们有一个非常复杂的Django应用程序,当前由apache/mod_wsgi提供,并部署在AWS ELB负载均衡器后面的多个AWS EC2实例上.客户端应用程序使用AJAX与服务器交互.他们还定期轮询服务器以检索其状态的通知和更新.我们希望删除轮询并使用网络套接字将其替换为"push".

因为任意实例处理来自客户端的Web套接字请求并保留这些Web套接字,并且因为我们希望将数据推送到可能不在提供推送源数据的同一实例上的客户端,所以我们需要一种方法来将数据路由到适当的实例,然后从该实例到适当的客户端Web套接字.

我们意识到apache/mod_wsgi与web套接字不兼容,并计划用nginx/gunicorn替换这些组件并使用gevent-websocket worker.但是,如果多个工作进程中的一个接收来自客户端的请求以建立Web套接字,并且如果工作进程的生命周期由主要的gunicorn进程控制,则不清楚其他工作进程如何处理,或者实际上是非枪支进程可以将数据发送到这些Web套接字.

具体情况是这样的:发出HTTP请求的用户被定向到一个EC2实例(主机),并且期望的行为是将数据发送给在完全不同的实例中打开web套接字的另一个用户.可以容易地设想一种系统,其中在每个实例上运行的消息代理(例如,rabbitmq)可以被发送包含要通过web套接字发送到连接到该实例的客户端的数据的消息.但是这些消息的处理程序如何访问在gunicorn的工作进程中收到的Web套接字?高级python Web套接字对象创建gevent-websocket并且可供工作人员使用,不能被pickle(它们是不支持pickle的实例方法),因此它们不能轻易地被工作进程共享到一些长时间运行的外部处理.

事实上,这个问题的根源在于如何通过外部进程访问由客户端的HTTP请求启动并由诸如gunicorn等服务器中的WSGI处理程序处理的Web套接字?用于处理HTTP请求的gunicorn工作进程似乎是正确的,它会产生长时间运行的线程以挂起到Web套接字并支持处理来自其他进程的消息,以便将消息发送到通过这些工作者连接的Web套接字流程.

任何人都可以解释一下Web套接字和基于WSGI的HTTP请求处理程序如何在我描述的环境中相互影响?

谢谢.

Ivo*_*Ivo 0

旨在处理 HTTP 请求的 Gunicorn 工作进程会生成长时间运行的线程来挂起 Web 套接字并支持处理来自其他进程的消息以将消息发送到通过这些工作进程附加的 Web 套接字,这似乎是不对的流程。

为什么不?毕竟这是一个长期运行的连接。一个长时间运行的线程来处理这样的连接似乎......对我来说绝对是自然的。

通常在这些事件情况下,写作与阅读是分开处理的。

当前正在处理 websocket 连接的工作人员将等待相关消息从消息传递服务器传来,然后将其传递到 websocket。

如果您愿意,您还可以使用 gevent 的异步友好队列来处理代码内消息传递。