通过粘性会话和WebSocket进行扩展 [英] Scaling with sticky sessions and websockets

问题描述

最初，我们有两个AWS EC2实例，它们的node.js在带有粘性会话的负载均衡器后面运行.随着负载的增加，将添加更多实例.

Initially we have two AWS EC2 instances with node.js running behind a load balancer with sticky sessions. As the load increases more instances are added.

但是我们在使用这种方法时遇到了问题.由于外出应用主要用于车间，因此负载通常会在较短的时间内(车间开始)增加，并且每个车间参与者都对前两个实例有粘性会话，而新实例几乎没有.因此，性能仍然很差.

But we are facing problems with this approach. As out application is mainly for workshops, the load usually increases within a short period of time (workshop start) and every workshop participant has a sticky session with the first two instances and the new ones have almost none. Because of this the performance stays bad.

首先想到的是:让我们禁用粘性会话.但这破坏了我们的websocket，因为它们需要粘性会话(至少这是我读过的内容).另一个问题是负载减少.实例关闭并且套接字连接也丢失.

First thought was: let's disable the sticky sessions. But that destroys our websockets because they need sticky sessions (at least this is what i've read). Another problem is with decreasing load. Instances shut down and socket-connections also get lost.

是否可以在实例之间转移用户会话或使Websocket在没有粘性会话的情况下工作(也许使用Redis)?

Is there an approach to shift user-sessions between instances or get websockets work without sticky sessions (maybe with Redis)?

推荐答案

解决方案是评论).

The solution was an Application Load Balancer (see comment).

1. 起初，我们不得不禁用轮询，因为这与其余的都不起作用.这是通过手动定义传输方式完成的.

1. At first we had to disable polling, because this did not work with the rest. This is done by defining the transports manually.

let ioSocket = io('', {
    path: '/socket.io-client'
    transports: ['websocket']

此后，我们设置了一个标准的应用程序负载平衡器，其中包含两个目标组:一个用于websocket，另一个用于所有其他请求. websocket目标组的规则通过正则表达式匹配特定路径:

After that we set up a standard application load balancer with two target groups: one for websockets and one for all other requests. The rule for the websocket target group matches a specific path via regex:

1. 最后一个问题是扩展:如果一个实例由于集群连接上的较低负载而关闭，则可能会丢失.客户端断开连接后，通过简单的重新连接即可解决此问题(在我们的示例中为角度应用程序):

1. Last problem was scaling: if one of the instances shuts down because of lower load on the cluster connections may get lost. This was fixed with a simple reconnect after a disconnect in the client (in our case an angular application):

[...]
this.socket.on('disconnect', () => {
    // Reconnect after connection loss
    this.connect();
});
[...]

这篇关于通过粘性会话和WebSocket进行扩展的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！