高可用性系统有哪些select？

你有很多select。 你可以使用哪些取决于你的网站是如何编码的。

单一状态紧密耦合
这个网站只能运行一个实例，因为…原因。 平行运行两个将是一个非常糟糕的主意，由于某种原因。 成为这种网站是非常罕见的。

CAP定理 ：在整个系统中的一致性是至关重要的，而不是完全分区容忍，这使得可用性成为主要的工程目标。

紧耦合，每个会话单一状态
这个网站只有在用户在同一个网站上进行互动时才能正常运行。 如果他们打错了服务器，事情可能会出错。

CAP定理：用户会话需要严格的一致性，但系统不需要它。 自失去会话以来，有些分区容错仍然是服务的退化，但整个系统仍然存在。

松散耦合，状态不重要
最具扩展性的选项是，如果状态保持不变，那么这种types的站点会在数据库层中保持会话状态。 打错了服务器，没关系，因为Web服务器刚刚打到数据库的状态。

CAP定理：用户会话对松散一致性很满意，分区容忍度非常高，这意味着可用性是最重要的。

单一国家 到目前为止最难做到这一点，这就是为什么网站几乎从未被编码的原因。 它需要一个且只有一个数据库或文件集，并且只有一个Web服务器，在HA服务器成员之间进行复制或卷传递，以便一旦第一个服务器死亡，另一个可以将其选中。 工程是非常棘手的，通常情况下，将网站重新编码为单一状态每个会话应用程序通常更容易，问题要简单得多。

但是，如果你没有select，你唯一的主要select就是心跳 。 获取一组服务器，configuration文件和数据库复制，并设置故障转移规则。 不容易。

单一系统映像对于网站来说是不可行的，因为创build高性能和可用系统的难度非常高。 SSI系统有很多工程背后，以确保一个单一的IPC空间和严格的系统级一致性，这往往使networking服务真的很慢。 最适用于那些需要物理节点间集成度的系统，而Web服务不是这样一个系统。 它的分区容忍度真的很差，这使得SSI成为一个糟糕的HA解决scheme。 这对于医pipe局来说不是一个捷径。 你会更好地与一个群集服务。

单个状态每个会话通常通过创build多个Web服务器并使用负载平衡器（如haproxy ，AWS Elastic Load Balancer（ elb ））或硬件系统（如F5 BigIP）来处理。 他们configuration了粘滞会话 ，每个用户会话被馈送到一台服务器。 当一个人死亡，其他人接pipe; 任何具有下拉框上的会话的用户都会重新启动，这就是生活。 编码您的网站，这样的会话中断不会损坏的东西。

“状态不重要”的处理方式与单一状态每个会话的处理方式相同，但关键区别在于缺less粘性会话。 负载平衡器被configuration为向池中的任何服务器提供每个请求，并且web服务器按请求基于数据库馈送状态。 当一台服务器死亡，没有人注意到。