我们有一个非常复杂的Django应用程序，目前由apache/mod_wsgi提供服务，并在多个AWS EC2实例上部署，这些实例都在AWS ELB负载均衡器后面。客户端应用程序使用AJAX与服务器进行交互。他们还会定期轮询服务器以检索其状态的通知和更新。我们希望删除轮询并使用Web套接字来替换它，从而实现“推送”。
由于任意实例处理来自客户端的Web套接字请求并保留这些Web套接字，并且因为我们希望将数据推送到可能不在提供推送源数据的相同实例上的客户端，因此我们需要一种方法来将数据路由到适当的实例，然后从该实例路由到适当的客户端Web套接字。
我们意识到apache/mod_wsgi与Web套接字不兼容，并计划使用nginx/gunicorn替换这些组件，并使用gevent-websocket worker。但是，如果其中一个或多个工作进程收到来自客户端建立Web套接字的请求，并且如果工作进程的生命周期由主gunicorn进程控制，则不清楚其他工作进程或实际上非gunicorn进程如何向这些Web套接字发送数据。
一个具体的案例是：发出HTTP请求的用户被引导到一个EC2实例（主机），并且期望的行为是将数据发送到在完全不同实例中打开Web套接字的另一个用户。人们可以轻松地想象一个系统，其中在每个实例上运行的消息代理（例如rabbitmq）可以发送包含要通过Web套接字发送到连接到该实例的客户端的数据的消息。但是，如何处理这些消息的处理程序访问在gunicorn的工作进程中接收到的Web套接字呢？由gevent-websocket创建的高级Python Web套接字对象并提供给工作进程无法进行pickling（它们是没有支持pickling的实例方法），因此它们不能轻松地被共享到某个长时间运行的外部进程中。
实际上，这个问题的根源在于Web套接字和基于WSGI的HTTP请求处理程序如何在我描述的环境中相互协作？似乎不“正确”，即gunicorn工作进程旨在处理HTTP请求，会生成长时间运行的线程来保持Web套接字，并支持从其他进程处理消息以发送消息到已通过这些工作进程附加的Web套接字。
有人能解释一下在我描述的环境中，Web套接字和基于WSGI的HTTP请求处理程序可能如何相互协作吗？
谢谢。
由于任意实例处理来自客户端的Web套接字请求并保留这些Web套接字，并且因为我们希望将数据推送到可能不在提供推送源数据的相同实例上的客户端，因此我们需要一种方法来将数据路由到适当的实例，然后从该实例路由到适当的客户端Web套接字。
我们意识到apache/mod_wsgi与Web套接字不兼容，并计划使用nginx/gunicorn替换这些组件，并使用gevent-websocket worker。但是，如果其中一个或多个工作进程收到来自客户端建立Web套接字的请求，并且如果工作进程的生命周期由主gunicorn进程控制，则不清楚其他工作进程或实际上非gunicorn进程如何向这些Web套接字发送数据。
一个具体的案例是：发出HTTP请求的用户被引导到一个EC2实例（主机），并且期望的行为是将数据发送到在完全不同实例中打开Web套接字的另一个用户。人们可以轻松地想象一个系统，其中在每个实例上运行的消息代理（例如rabbitmq）可以发送包含要通过Web套接字发送到连接到该实例的客户端的数据的消息。但是，如何处理这些消息的处理程序访问在gunicorn的工作进程中接收到的Web套接字呢？由gevent-websocket创建的高级Python Web套接字对象并提供给工作进程无法进行pickling（它们是没有支持pickling的实例方法），因此它们不能轻松地被共享到某个长时间运行的外部进程中。
实际上，这个问题的根源在于Web套接字和基于WSGI的HTTP请求处理程序如何在我描述的环境中相互协作？似乎不“正确”，即gunicorn工作进程旨在处理HTTP请求，会生成长时间运行的线程来保持Web套接字，并支持从其他进程处理消息以发送消息到已通过这些工作进程附加的Web套接字。
有人能解释一下在我描述的环境中，Web套接字和基于WSGI的HTTP请求处理程序可能如何相互协作吗？
谢谢。