我的情况是,我们目前正在编写一个在线应用程序,它在服务器端使用Node.js和WebSocket监听器。我们有两个不同的部分:一个服务页面,使用node.js和express + ejs,另一个是完全不同的应用程序,只包含用于websockets的socket.io库。 所以这里我们来讨论websockets部分的可伸缩性问题。
我们发现的一个解决方案是在服务器之间使用redis和共享套接字信息,但由于体系结构,它需要共享大量其他信息,这将在服务器上产生巨大的开销。
在这个介绍之后,我的问题是 - 是否可以为websockets使用基于cookie的负载平衡?这样就可以说用户与cookie server = server1的每个连接都将被转发到server1,并且每个与cookie server = server2的连接都将是fw到server2,没有这样的cookie的连接将是fw到最不繁忙的服务器。
更新:正如一个'答案'所说 - 是的,我知道这存在。只是不记得那个名字是粘性会话。但问题是 - 这对websockets有用吗?有任何可能的并发症吗?
答案 0 :(得分:5)
我们的Node.js生产堆栈中出现了类似的问题。我们有两个使用WebSockets的服务器,它们适用于正常使用情况,但偶尔负载均衡器会在两个服务器之间弹出这些连接,这会导致问题。 (我们在后端有适当的会话代码应该修复它,但没有正确处理它。)
我们尝试在这些服务器前面的Barracuda负载均衡器上启用Sticky Session,但发现由于它的运行方式会阻止WebSocket流量。我没有仔细研究过为什么,因为在线提供的信息很少,但似乎这是由于平衡器如何剥离HTTP请求的标头,抓取cookie并将请求转发到正确的后端服务器。由于WebSockets从HTTP开始,然后升级,负载均衡器没有注意到连接的差异,并尝试进行相同的HTTP处理。这将导致WebSocket连接失败,从而断开用户连接。
以下是我们目前正在运作的非常好的方法。我们仍然在后端服务器前使用Barracuda负载平衡器,但我们没有在负载平衡器上启用Sticky Sessions。在我们的后端服务器上,我们的应用程序服务器前面是HAProxy,它可以正确地支持WebSockets,并且可以以“环形”方式提供Sticky Sessions。
请求流列表
请求流程图
WebSocket Request /--> Barracuda 1 -->\ /--> Host 1 -->\ /--> App 1
-------------------> --> -->
\--> Barracuda 2 -->/ \--> Host 2 -->/ \--> App 1
当箭头返回到一个请求时,这意味着请求可以流向流中的任一点。
HAProxy配置详细信息
backend app_1
cookie ha_app_1 insert
server host1 10.0.0.101:80011 weight 1 maxconn 1024 cookie host_1 check
server host2 10.0.0.102:80011 weight 1 maxconn 1024 cookie host_2 check
在上面的配置中:
cookie ha_app_1 insert
是使用的实际Cookie名称cookie host_1 check
或cookie host_2 check
设置Cookie值