如何避免给定分布式架构的单点故障

Question

我经历了这个video - Scalability Harvard Web Development David Malan

这是我被卡住的地方。解释问题 -

让我们假设LB使用循环法。

根据第一张图片，所有服务器都在其本地空间中存储会话，而其他服务器无法访问这些会话。如果下次发出相同的请求，并且如果LB将此请求重定向到另一个服务器，则该服务器将询问身份验证。从用户的角度来看，这非常令人恼火。

根据第二张图片，所有服务器都在共享会话。在这种情况下，当下一个请求来自同一客户端时，LB会重定向到另一个服务器。现在，它不是要求身份验证，而是从Session主机获取信息。

以上视频链接中提到了这一点。

问题 -

1. 现在会话主机成为单点故障。如果主机出现故障，则会严重影响可用性。我们怎样才能避免这种情况？

Answer 1

你有这些选择（假设会话不能不惜任何代价丢失）

1）会话数据存储是高度可用的数据存储。例如：您可以将MongoDB副本集用于此类会话存储。它由MongoDB的三个节点组成，其中包含一个主节点和两个从节点（最小值），当主节点关闭时，其中一个节点被提升为主节点。这次选举可能需要几秒钟，但会议不会丢失。

2）使用内存数据共享库，它可以进行数据分区和复制。一个例子是Hazelcast for Java。它为您提供跨Web层的对象级别共享，您可以在此处存储共享的会话。请注意AFAIK在这种情况下没有数据持久性（在磁盘上）。

3）到目前为止，我使用的最具扩展性的方法是拥有客户端会话而没有服务器端数据/会话存储。在这种情况下，您可以做的是在每个应用服务器中存储一个非常长的密钥，并在使用此密钥加密数据后设置cookie中的所有数据。这种方法的唯一问题是您需要对会话中存储的内容非常有选择性，因为cookie上的数据大小有限制。这种加密是双向的。大多数基于SAAS的工具都使用这种方法。

Answer 2

将会话主机实现为复制数据存储有助于消除单点故障。例如，使用像Hazelcast这样的复制缓存将保持缓存的复制和分发，从而消除单点故障。还有其他像Memcached和Mongo。可以通过虚拟IP地址实现对这些的自动故障转移。

Answer 3

出于这个原因，通常会话主机（例如memcache）前面有一个VIP（虚拟IP），并且有多个主机。在分布式体系结构中，您通常希望拥有1-N个主机。大多数大规模运营的公司都会使用Couchbase（memcahce存储桶）等数据存储来存储会话状态，因为它具有快速，冗余和高度可扩展性。