我经历过这个video - Scalability Harvard Web Development David Malan
这就是我陷入困境的地方。解释问题 -
假设 LB 使用循环法。
根据第一张图片，所有服务器都将 session 存储在其本地空间中，其他服务器无法访问该空间。如果下次有相同的请求，并且 LB 将此请求重定向到另一台服务器，则该服务器将询问身份验证。从用户的角度来看，这非常令人恼火。
根据第二张图片，所有服务器都在共享 session 。在这种情况下，当下一个请求来自同一客户端时，LB 会重定向到另一台服务器。现在，它将从 session 主机获取信息，而不是要求身份验证。
上面的视频链接中提到了这一点。
问题 -
- 现在 session 主机成为单点故障。如果主机宕机，将会严重影响可用性。我们怎样才能避免这样的情况发生？
最佳答案
您有这些选项(假设 session 是不惜任何代价都不能丢失的东西)
1) session 数据存储是一个高可用的数据存储。例如:您可以将 MongoDB 副本集用于此类 session 存储。它由 MongoDB 的三个节点组成，其中一个主节点和两个从节点(最少)，当主节点出现故障时，其中一个节点将提升为主节点。这次选举可能需要几秒钟，但 session 不会丢失。
2) 使用内存数据共享库来进行数据分区和复制。一个例子是 Java 版的 Hazelcast。它为您提供跨 Web 层的对象级共享，您可以在此处存储共享的 session 。请注意，据我所知，在这种情况下(在磁盘上)没有数据持久性。
3)到目前为止，我使用的最具可扩展性的方法是使用客户端 session ，而不使用服务器端数据/ session 存储。在这种情况下，您可以做的是在每个应用程序服务器中存储一个很长的 key ，并在使用该 key 加密数据后将所有数据设置在cookie中。这种方法的唯一问题是，您需要对 session 中存储的内容非常有选择性，因为 cookie 的数据大小有限制。这种加密是双向的。大多数基于 SAAS 的工具都使用这种方法。
关于session - 如何避免给定分布式架构的单点故障，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35860262/