meteor之SockJS 和 meteor : what if load balancer do not support sticky sessions

我正在探索 Meteor 的平衡选项。 This文章看起来很酷，它说应该支持以下负载平衡 Meteor:

1. Mongo 优化。否则，一个 Meteor 实例可能需要十秒才能从另一个实例获取更新，因为将使用轮询 Mongo 驱动程序，它每十秒轮询一次数据库。
2. 网络套接字。这也很清楚 - 否则客户端将回退到 HTTP 和长轮询，这会起作用，但它不如 Websocket 酷。
3. “SockJS 需要的”粘性 session 。问题来了:

据我了解，“粘性 session 支持”是指在一个客户端的 session 期间将其分配给同一台服务器。它是必不可少的吗？如果我根本不配置粘性 session ，可能会发生什么？

这是我自己想出来的:

1. 因为Meteor将发送给客户端的所有数据都存储在内存中，如果客户端连接到X台服务器，那么将消耗X倍的内存
2. 对于同一用户，例如在不同的选项卡或窗口中，可能会出现一些轻微(或严重，如果没有操作日志)延迟，这可能会令人惊讶。
3. 如果 SockJS 重新连接并希望一些数据在重新连接后保持不变，那将是一段糟糕的时光。我不确定 SockJS 是如何工作的，这一点是否有效？

会发生什么坏事？这三点看起来不是很糟糕:数据有效、可用，可能以额外的内存消耗为代价。

请您参考如下方法:

基础知识

需要粘性 session 来确保服务器可以正确管理浏览器的内存 session 。

首先让我解释一下为什么需要粘性 session :

每个使用普通发布游标的发布都会跟踪客户端可能拥有的任何集合，因此当某些内容发生变化时，它知道将什么发送回客户端。如果需要 DDP 连接，这将适用于每个 Meteor 应用程序。 websockets和sockjs就是这样

此外，可能还有其他客户端 session 状态存储在变量中，但那些是边缘情况(例如，您将用户状态存储在变量中)。

当服务器断开连接并重新连接时会出现问题，但连接可能会以某种方式转移到另一个节点(无需重新建立新连接)——该节点不知道客户端的数据，因此行为可能会变成有点奇怪。

SockJS 和长轮询的问题

SockJS 还有一个问题。 SockJS 在回退到长轮询时使用 websocket 仿真。

使用长轮询，每次新数据可用时，都会尝试新连接/新http请求。

如果未启用粘性 session ，这些连接中的每一个都将随机分配给不同的节点/发电机。

因此，您有 50% 的机会(在随机情况下)服务器不知道每次有新数据可用时客户端的 DDP session every。

然后它会强制客户端重新协商连接/忽略客户端 DDP 命令，你最终会在客户端上得到非常奇怪的行为。

其中一半会到达错误的节点: