meteor - SockJS 和流星：如果负载均衡器不支持粘性会话怎么办？

Question

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

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

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

这是我自己想到的：

1. 因为 Meteor 将发送给客户端的所有数据都存储在内存中，如果客户端连接到 X 个服务器，那么将消耗 X 倍的内存
2. 同一用户可能会在不同的选项卡或窗口中出现一些次要（或主要，如果没有 oplog）滞后，这可能会令人惊讶。
3. 如果 SockJS 重新连接并希望一些数据在重新连接时保持不变，那将会很糟糕。我不确定 SockJS 是如何工作的，这点有效吗？

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

Answer 1

基本

需要粘滞会话以确保服务器可以正确管理浏览器的内存会话。

首先让我解释一下为什么需要粘性会话：

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

此外，可能还有其他客户端会话状态存储在变量中，但您将是边缘情况（例如，您将用户的状态存储在变量中）。

当服务器断开连接并重新连接时会出现问题，但不知何故，连接可能会转移到另一个节点（没有重新建立新连接）——它不知道客户端的数据，所以行为可能会有点奇怪。

SockJS 和长轮询的问题

对于 SockJS，还有一个额外的问题。SockJS 在回退到长轮询时使用 websocket 仿真。

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

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

因此，每次有新数据可用时，服务器都有 50% 的机会（在随机的情况下）不知道客户端的 DDP 会话。

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

其中一半将是错误的节点：