如何衡量系统的高可用性?

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

对于系统高可用这个概念，基本功是程序异常处理，仅能在正常情况下运行的程序不叫高可用，在异常情况下仍然可用才行。

另外是机房容灾，即当个别机器损坏，或者个别机房网络割接时，仍可正常运作。

当遇到性能瓶颈时，系统容易扩展，可横向扩展解决，比如多部署几个程序即可解决，无需更改代码

最后无需过多的人工干预，7*24都能工作，遇错自动调整，不必投入人力时刻关注程序的状态。

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。 高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

只要增加服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的，难点在于：如何在架构各层进行可水平扩展的设计。

高可用性（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性(一直都能用)。

比如现在redis的高可用的集群方案有： Redis单副本，Redis多副本（主从），Redis Sentinel（哨兵），Redis Cluster，Redis自研。

首先我们再来明确一下CAP里的A的标准（非常高的标准）

这个标准可能和我们平时用的可用性是不一样的。比如你肯定会听说有这样一个概念，5个9可用。这里的可用性是关于“time system available” 除以 “total time”

所以定义上有很大的不同。CAP里的可用性不是being available的意思。而且主要讨论当系统处于网络分区情况下的该有的行为。

但是，我们还是可以用CAP里的A的术语，来定义高可用和部分可用

区别在于，高可用允许有些没挂掉的节点不给出响应。但是所有请求总有一部分节点是肯定能给出响应的。（如共识系统zookeeper）

部分可用就是允许有一些请求，所有节点都无法给出响应,有一些会有一部分节点肯定可以给出响应。

基于前面2节，系统可以划分到4类。

现在我们对一些系统做分类，▲意味着是网络分区下的典型，绝大多数的表现，△意味着网络分区下的有可能的一些表现

上图第一行是 一个WEB应用连接一个SQL DB 是一个CA系统，基本是完全不可用的当发生网络分区时。

Typical CP big data system 是一个CP的系统。典型的情况是网络分区下是高可用，有一些是部分可用或完全不可用。

下面我们来逐行分析

这个系统可以宣称自己是CP或者CA（我无法处理partition的情况）都可以。

说CP对市场营销是有好处的：虽然在有分区的情况下系统无法正常工作，但它被标记为“耐分区”。 直到有一个分区，最终用户发现CP的真正含义

说CA强调了网络分区是系统的实际问题，应该特别注意网络。 从软件工程的角度来看，这似乎是最好的类别。

之前分析过了是 non-CA的，意思是这个系统不是强一致，在网络分区下，不可用。

这个系统上述的2PC是带逃生窗口的2PC，可以被划分到下述2类。

CP系统，上一章已经分析过了。同时是高可用的，只要在多数的那个分区里，可以响应任意请求。

这是一个有很多种可用性的类型。CP大数据存储对于某些分区可能是高度可用的，但并非对每个分区都可用。 某些分区至少有部分可用性

这或多或少是直观的：数据量很大，因此无法容纳所有可能的分区。 然后，根据网络分区，我们可以找到：

一个分区具有所有数据的副本：这是高可用性。

没有一个分区具有所有数据的副本，并且使用大数据存储的应用程序无法应对这种情况。 整个系统不可用。

没有一个分区具有所有数据的副本，但是应用程序可以处理丢失的数据。 那是部分可用性。 这取决于应用程序，因为应用程序必须显式管理这种情况。 他们中的大多数将无法应付这种情况。

为了说明所有这些，让我们来看一个实际的实现。 下面数学中的逻辑是使用最乐观的计算：在大多数实际情况下，实际可用性会更糟。

HDFS，Hadoop分布式文件系统。 HDFS是一个CP大数据系统：如果将系统分为两个分区，则只有一个分区将继续为查询提供服务。

其特点是：

所有这些都是可配置的，但是此处提到的值是常用的。 假设我们有10个机架，在复制整个集群之前有200 Tb的数据。 也就是说，每个HDFS块有160万块，每块128 Mb。

将有两个分区：一个分区具有1至9的机架，另一个分区具有10的机架。有了这样的分区，前9个机架可以继续满足所有请求：通过构造，它们具有所有数据，就像将所有块写入机架一样 10个也被复制到另一个机架中。 但是，机架10中的客户端无法将请求发送到这9个机架，因此该系统总体上是高度可用的，但没有CAP可用。（因为要求所有请求到任意一个没有挂掉的节点都可用，显然机架10不符合要求）

请注意，即使机架10具有所有数据，机架10中的客户端仍将无法在本地执行任何工作：CP系统不能使两个分区（CAP）并行运行。（这样会违反一致性，因为数据必须同步复制出去）

为了高度可用，该分区至少需要每个块一个副本。 现在，如果我们只有50％的机架，那么拥有至少一份数据副本的概率是多少？ 为了进行计算，我们简化一下，说每个块都复制在3个不同的机架上。 因此，将所有副本放在另一个分区中的概率为：

初版：10个中有5个坏机架

第二份副本：9个中有4个坏机架

第三副本：8个坏机架中的3个

这样，我们得到一个块：（5/10） （4/9） （3/8），即8％。 因此，对于单个块，我们在主分区中至少有一个副本的可能性约为92％。 很好，但是我们有160万个区块。 所有块中至少有一个副本的概率为92%。 160万个块，实际上为零。 从CAP分类的角度来看，这并没有任何改变：它仍然是CP，因为CP允许我们在任何节点上的某些请求失败。 但是该系统不再具有高可用性。

首先最终一致不是强一致的，其次他不是CAP的可用。在大多数这样的系统里它可以保持高可用

大多数网络分区将导致一个有足够数据的分区与另一个没有足够数据的分区之间的分裂。 对于这些分区，系统作为存储是高度可用的，但对于CAP不可用：第二个分区无法处理所有请求（如果有）。

如果配置了数据中心之间的复制，则对于数据中心之间的分区（仅对此分区），系统将是CAP级别的可用。(因为任意请求在任意机器上都可以得到响应，因为数据中心包含了所有数据）

虽然不可能使“最终一致的大数据系统”成为AP，但也很难使任何最终一致的系统都属于该类别。 这是因为AP系统必须

但是，即使在技术上可以构建最终一致的AP系统时，某些应用程序仍可能具有安全约束，这将使断网的 *** 作变得困难。 对于今天的某些业务应用程序，有一些关于“限时访问”的要求，这些要求可以在几分钟内制定。 访问权限和身份验证应用程序是愿意选择“可用性”而不是“一致性”的应用程序的典型示例，但是它们也受到这些“限时访问”要求的限制。

市场营销中使用的CAP分类与CAP定理的实质无关。大部分将自己描述为CP的系统并非全部都不具有分区容错性，并且大多数声称是AP的系统也不是全部可用。以下是一些简要介绍：

埃里克·布鲁尔（Eric Brewer）在2012年的论文 C3 ].中已经提到了这里提出的许多观点。 在2000年的演讲 C1 ,

中，他已经研究了部分可用数据的细节。

而且，Daniel Abadi在[ C8 中已经指出：“我对CAP的主要问题是，它将CAP集中在所有人身上，这是使每个人都专注于一致性/可用性之间的权衡，从而导致人们认为NoSQL系统放弃一致性的原因是为了获得可用性。 但是，实际上，大多数放弃一致性的应用最终并没有获得更多的可用性。

---