SockJS 和meteor：如果负载均衡器不支持粘性会话怎么办？
yep*_*ons 3 load-balancing meteor sockjs
我正在探索 Meteor 的平衡选项。这篇文章看起来很酷，它说应该支持以下内容来负载平衡 Meteor：
- 蒙戈·奥普泰林。否则，一个 Meteor 实例可能需要长达 10 秒的时间才能从另一个实例获取更新，因为将使用轮询 Mongo 驱动程序，该驱动程序每 10 秒轮询并比较一次数据库。
- 网络套接字。这也很清楚 - 否则客户端将回退到 HTTP 和长轮询，这会起作用，但它不如 Websocket 那么酷。
- 粘性会话“SockJS 需要”。问题来了：
据我了解，“粘性会话支持”是指在会话期间将一个客户端分配给同一台服务器。这是必要的吗？如果我根本不配置粘性会话，可能会发生什么？
这是我自己想到的：
- 因为 Meteor 将所有发送给客户端的数据存储在内存中，如果客户端连接到 X 个服务器，那么将消耗 X 倍的内存
- 对于同一用户，在不同的选项卡或窗口中可能会出现一些较小的（或主要的，如果没有 oplog）延迟，这可能会令人惊讶。
- 如果 SockJS 重新连接并希望一些数据在重新连接后仍保留，那么情况会很糟糕。我不确定 SockJS 是如何工作的，这一点有效吗？
会发生什么坏事？这三点看起来并不是很糟糕：数据有效、可用，可能是以额外的内存消耗为代价的。
基本
需要粘性会话来确保服务器可以正确管理浏览器的内存会话。
首先让我解释一下为什么需要粘性会话：
使用普通发布游标的每个发布都会跟踪客户端可能拥有的任何集合，因此当某些内容发生更改时，它知道将哪些内容发送回客户端。如果需要 DDP 连接，这将适用于每个 Meteor 应用程序。websockets和sockjs就是这种情况
此外，可能还有其他客户端会话状态存储在变量中，但这些状态属于边缘情况（例如，您将用户的状态存储在变量中）。
当服务器断开连接并重新连接时，问题就会发生，但不知何故，连接可能会转移到另一个节点（无需重新建立新连接）——该节点不知道客户端的数据，因此行为可能会变得有点奇怪。
SockJS 和长轮询的问题
对于 SockJS 还有一个额外的问题。SockJS 在回退到长轮询时使用 websocket 模拟。
通过长轮询，每次有新数据可用时都会进行新的连接尝试/新的 http 请求。
如果未启用粘性会话，则每个连接将被随机分配给不同的节点/发电机。
因此，每次有新数据可用时，服务器有 50% 的机会（在随机情况下）不知道客户端的 DDP 会话。
然后，它会强制客户端重新协商连接/忽略客户端 DDP 命令，最终会在客户端上出现非常奇怪的行为。
其中一半会到达错误的节点：
