Skip to main content
 首页 » 编程设计

python之在负载均衡器 : django-channels 后面运行多个 daphne 实例

2025年01月19日33lautakyan007

我正在使用 django-channels 为我的应用程序添加 HTTP2 和 WebSocket 支持。我找不到很多关于如何缩放 channel 的文档。下面是我的 nginx 配置,它对运行在同一台机器但不同端口上的多个 daphne 实例进行负载平衡。这是正确的做法吗?

upstream socket { 
    least_conn; 
    server 127.0.0.1:9000; 
    server 127.0.0.1:9001; 
    server 127.0.0.1:9002; 
    server 127.0.0.1:9003; 
} 
 
server { 
    listen 80; 
    server_name 127.0.0.1; 
 
    location = /favicon.ico { access_log off; log_not_found off; } 
 
    location /static/ { 
        root /home/niscp/home-screen; 
    } 
 
    location /nicons/ { 
        root /home/niscp/home-screen; 
    } 
 
    location / { 
        include uwsgi_params; 
        uwsgi_pass unix:/home/niscp/home-screen/home-screen.sock; 
    } 
 
    location /ws/ { 
        proxy_http_version 1.1; 
        proxy_set_header Upgrade $http_upgrade; 
        proxy_set_header Connection "upgrade"; 
        proxy_pass http://socket; 
    } 
} 

除此之外,我正在运行 workers 的各个实例,以按以下方式收听各个 channel :

python manage.py runworker --only-channels=websocket.connect 
python manage.py runworker --only-channels=websocket.receive 
python manage.py runworker --only-channels=websocket.disconnect 

我有 uwsgi 以 django 通常处理它们的方式处理所有 http 请求。 daphne 和 workers 所做的只是处理 WebSocket 请求。 这是扩展 django-channels 的可行方法,还是我可以做得更好?

请您参考如下方法:

这里有几件事。首先,我认为在不同进程中运行不同类型的请求不会给您带来多大好处。您的断开连接处理程序可能会非常轻巧——除了清理之外不会做太多事情。 Connect 也可能不会做太多事情,而 receive 将承担大部分负载。

您打赌使用 --threads 参数并启动多个线程。您当前的设置只会为每种类型的处理程序运行一个线程。

runworker 的工作方式是它通过您的 channel 层(例如 Redis)与 Daphne 通信。所有的 worker 都在听一个队列。当一个请求进来时,一个工作人员将处理它。当该 worker 正在处理请求时,其他 worker 将等待后续请求并处理它们。一旦他们发送响应,他们就会返回收听队列。如果没有指定 --only-channels,每个进程将拉出请求并尽可能快地处理它们,没有一个进程会等待。

您可以通过运行多个进程和 --threads 参数来找到线程/工作线程的最佳平衡。您还可以为繁重的 channel 预留工作人员,这样他们就不会降低您的网站。

拥有多个达芙妮实例会有所帮助。但由于它们所做的只是在您的服务器和工作人员之间发送消息,您可能看不到运行其中 4 个的好处。

此处所述的所有内容均不适用于 Channels 2。这是针对旧版本的 Django Channels。