基于Cookie的WebSockets的负载平衡?

我的情况是,我们目前正在编写一个在线应用程序,它使用WebSocket侦听器在服务器端使用Node.js。 我们有两个不同的部分:一个服务页面,使用node.js和express + ejs,另一个是完全不同的应用程序,其中只包括用于websocket的socket.io库。 所以在这里我们来看看这个websockets部分的可伸缩性问题。

我们发现的一个解决scheme是使用redis和服务器之间共享套接字信息,但是由于架构,它将需要共享其他信息的负载,这将在服务器上造成巨大的开销。

在介绍之后,我的问题是 – 是否可以使用基于cookie的websocket负载平衡? 因此,可以说每个从用户与cookie服务器= server1连接将始终转发到server1和每个连接与cookie服务器= server2将fw到server2和连接没有这样的cookie将fw到最不繁忙的服务器。

更新:正如一个“答案”所说 – 是的,我知道这存在。 只是不记得那个名字是粘滞的会议。 但问题是 – 这是否适用于websockets? 有没有可能的并发症?

       

网上收集的解决方案 "基于Cookie的WebSockets的负载平衡?"

我们的Node.js生产堆栈中出现了类似的问题。 我们有两台使用WebSockets的服务器,这些服务器可以正常使用,但偶尔负载均衡器会反弹这两个服务器之间的连接,这会导致问题。 (我们在后端应用程序代码已经解决了,但没有正确处理它。)

我们尝试在这些服务器前面的Barracuda负载均衡器上启用Sticky Session,但发现它会阻塞WebSocketstream量,原因是它如何运行。 我还没有研究为什么,尽可能less的信息可以在线获得,但是这似乎是由于平衡器如何剥离HTTP请求的标题,抓取cookie并将请求转发到正确的后端服务器。 由于WebSockets以HTTP方式启动,但随后升级,负载平衡器没有注意到连接的差异,并尝试执行相同的HTTP处理。 这将导致WebSocket连接失败,断开用户连接。

以下是我们目前拥有的工作得很好的地方。 我们仍然在后端服务器前使用梭子鱼负载均衡器,但是我们没有在负载均衡器上启用粘滞会话。 在我们的后端服务器上,在我们的应用程序服务器之前是HAProxy,它可以正确支持WebSocket,并且可以以“迂回”的方式提供粘滞会话。


请求stream列表

  1. 传入客户端请求命中主要梭子鱼负载平衡器
  2. 负载平衡器转发到任一个活动的后端服务器
  3. HAProxy收到请求并检查新的“粘性cookies”
  4. 基于cookie,HAProxy转发到正确的后端应用程序服务器

请求stream程图

WebSocket Request /--> Barracuda 1 -->\ /--> Host 1 -->\ /--> App 1 -------------------> --> --> \--> Barracuda 2 -->/ \--> Host 2 -->/ \--> App 1 

当箭头返回到一个请求时,这意味着请求可以stream向stream中的任一点。


HAProxyconfiguration详细信息

 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 

在以上configuration中:

  • cookie ha_app_1 insert是使用的实际cookie名称
  • cookie host_1 checkcookie host_2 check设置cookie值