基于Cookie的WebSockets负载平衡？

我的情况是，我们目前正在写它使用Node.js的服务器端与网页套接字监听器的在线应用。我们有两个不同的部分：一个服务页面并使用node.js和express + ejs，另一个是完全不同的应用程序，它只包含用于websocket的socket.io库。所以我们来看这个websockets部分的可伸缩性问题。我们发现基于Cookie的WebSockets负载平衡？

一种解决方案是使用Redis的和服务器之间共享信息插座，但由于建筑，将需要的其他资料，这是要在服务器上创建巨大的开销负载的共享。

这个介绍之后，我的问题是 - 有可能使用基于cookie的负载平衡的WebSockets？因此，可以说，来自用户与cookie服务器= server1的每个连接都将始终转发到server1，并且每个使用cookie server = server2的连接都将fw到server2，并且没有此cookie的连接将会fw到最不繁忙的服务器。

UPDATE：作为一个“答案”说 - 是的，我知道这存在。只是不记得那个名字是粘滞的会议。但问题是 - 这是否适用于websockets？有没有可能的并发症？

来源

2012-07-25 AlexKey

这是一个问题，我很感兴趣，也只是我不太看这个问题从浏览器的负载均衡传入的连接（它只会打其中一台服务器，并坚持下去），我更感兴趣的是你如何从后端推送到这些服务器。就像，我有后端服务器执行实际工作，然后它会通过套接字将消息推送到websockets服务器 - 如果我有群集，我怎么知道推送到哪个服务器？我目前的想法是将所有打开的连接列表保存在中央数据库的某个位置，不确定是否是最好的方式。 – KOHb 2013-01-17 15:43:40

@KOHb我在套接字服务器后面没有任何额外的后端。所以对我来说这更简单。但从你说的话我会尝试Redis服务器为此目的。 – AlexKey 2013-01-21 11:30:31

我们有一个类似的问题在我们的Node.js生产堆露面。我们有两台使用WebSockets的服务器，这些服务器可以用于正常的使用情况，但偶尔负载平衡器会反弹这两个服务器之间的连接，这会导致问题。（我们在后端应用程序代码已经修复了它，但没有正确处理它。）

我们尝试在这些服务器前面的梭子鱼负载平衡器上启用粘滞会话，但发现它会阻塞WebSocket由于运营方式而产生的流量。我还没有研究过为什么，尽可能少的在线信息，但看起来这是由于平衡器如何剥离HTTP请求的标题，抓取cookie并将请求转发到正确的后端服务器。由于WebSockets始于HTTP然后升级，负载均衡器没有注意到连接的差异，并会尝试执行相同的HTTP处理。这会导致WebSocket连接失败，从而断开用户连接。

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

请求流程列表

传入客户端请求命中初级梭子鱼负载均衡
负载平衡器转发给任一活性后端服务器
HAProxy的接收针对该请求，并检查新的“粘性的cookie”
基于cookie的，HAProxy的转发到正确的后端应用服务器

请求流程图

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值

来源

2012-08-08 20:36:31

谢谢你的详细解答。但不幸的是，我们仍然需要为套接字连接使用粘滞会话。你代理管道还是重定向它？ – AlexKey 2012-08-19 10:04:07

由于WebSocket协议的研究结果，我们决定坚持以下解决方案： - 上handhsake步负载均衡套接字连接（它是好的，因为握手只是HTTP）与粘性会话，而不是代理管，但其重定向到 - 在情况下，如果状态的变化 - 力重新连接的客户端，在那里它再次将被负载平衡，以适当的服务器上的握手 - 服务器R子域网络内的暴露（不便等s1-socket.example.com，s2-socket.example.com等）但是我们还没有实现。一旦我们有，我会更新你。 – AlexKey 2012-08-19 10:12:14

你的第一个评论：我们仍然需要使用粘性会话，以及，上面的回答是，我们如何实现粘性会话我们自己的方式绕过该负载平衡器的粘性会话使用。你的第二个评论：这听起来像一个应该为你工作的场景。尽管硬件负载平衡器未被使用，但它仍然与我们的非常相似。我们使用HAProxy作为我们唯一提供所需功能的负载均衡器。 – 2012-08-20 17:18:09

基于Cookie的WebSockets负载平衡？

回答

相关问题