粘性负载均衡

如果计划在不同的进程或机器之间分配连接负载,则必须确保与特定会话ID关联的请求连接到发起它们的进程。

这是由于某些传输(如xhr轮询或jsonp轮询)依赖于在“socket”的生命周期内触发多个请求。如果不启用粘性负载均衡,这将导致很可怕:


Error during WebSocket handshake: Unexpected response code: 400

这意味着升级请求被发送到一个未知socket id的节点,因此是HTTP 400响应。

为了说明为什么需要这样做,请考虑向所有连接的socket发出事件的示例:


io.emit('hi',"all sockets")

很有可能这些socket中的一些可能有一个活动的双向通信通道,比如WebSocket,我们可以立即对其进行写入,但其中一些socket可能正在使用长轮询。

如果他们使用的是长轮询,那么他们可能已经或可能没有发送一个我们可以写入的请求。他们可能在这些请求之间。在这些情况下,这意味着我们必须在进程中缓冲消息。为了让socket在发送请求时成功地声明这些消息,最简单的方法是将连接路由到同一进程。

如上所述,WebSocket传输没有这个限制,因为基础TCP连接在socket和给定服务器之间保持打开状态。这就是为什么你可能会找到一些只使用WebSocket传输的建议:

const client = io('https://io.yourhost.com',{
    //警告:在这种情况下,没有回滚到长轮询
    transports:["websocket"] //  或者 [ 'websocket', 'polling' ], 这两者都一样
})

这两种方法都意味着,当无法建立WebSocket连接时,不会出现长轮询回退,这实际上是socket.io的关键功能之一。在这种情况下,您应该考虑使用原始WebSocket,或者像robust-WebSocket那样的包装器。

为了实现粘性会话,有两个主要解决方案:

  • 基于起始地址路由客户端
  • 基于cookie路由客户端

results matching ""

    No results matching ""