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

【问题标题】：How to avoid single point of failure from given distributed architecture如何避免给定分布式架构的单点故障
【发布时间】：2016-06-21 23:29:04
【问题描述】：

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

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

假设 LB 使用的是循环法。

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

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

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

问题 -

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

【问题讨论】：

在您的负载均衡器中实施粘性会话逻辑。也许这会起作用。或者使用客户端会话。
在客户端保存信息称为Cookies。但是你不能节省太多。这是 session 和 cookie 之间的一个主要区别。

标签： session architecture scalability high-availability distributed-system

【解决方案1】：

您有这些选项（假设会话是无论如何都不能丢失的）

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

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

【讨论】：