分布式系统详解--基础知识（CAP）

前面呢，文章写到了分布式系统详解--基础知识（通信），在RPC中看到通信为题的重要性，但是分布式系统当中又要牵扯到另外一个地方，就是数据的一致性（Consistency）、可用性（Availability）和容错性（Partition tolerance）。那这三个问题能够解决么，怎么解决的呢？那我们这篇文章就说一下CAP他们之间的"爱恨情仇~~"。

一、CAP定理图

那我们详细来介绍一下CAP。

1.1 CAP理论的来历

CAP呢，是按照美国著名科学家 Eric Brewer 在 2000 年提出的理论，当技术架构从集中式架构向分布式架构演进，会遇到 “CAP 定律”的瓶颈。我们可以从上面的图中看出的是，可用性、一致性和分区容错性，数据处理系统不能同时满足。那为什么不能满足呢？这三个名词又是具体的代表哪一些含义呢？

二、 CAP-Consistency（一致性）

2.1 一致性定义

在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

2.2 一致性模型

让我们来看看维基百科上关于一致性模型用于分布式系统的几个一致性模型的类型。参考网址如下请点击：

一致性模型。https://en.wikipedia.org/wiki/Consistency_model#Relaxed_Memory_Consistency_Models

其实，一致性模型是数据和进程之间的一个约定。一般情况下，一个数据项上执行读操作时，它期待该操作返回的是该数据在其最后一次操作之后的结果。在没有全局时钟的情况下，精确的定义哪一次操作是最后一次操作是非常困难的。所以就有了一系列的一致性模型。

假设出现以下情况：

行X在节点M和N上复制
客户端A将行X写入节点M.
在一段时间t之后，客户端B从节点N读取行X.

一致性模型必须确定客户端B是否看到来自客户端A的写入。

扫描二维码关注公众号，回复： 3631469 查看本文章

主备份协议示例

当客户端请求写入时，写入请求将转发到主服务器。主服务器向备份发送请求以执行更新。然后，服务器从所有备份接收更新确认，并将写入完成确认发送给客户端。任何客户端都可以在本地读取上次可用的更新此协议的权衡是发送更新请求的客户端可能需要等待很长时间才能获得确认才能继续。可以通过在本地执行更新来解决此问题，然后请求其他备份执行其更新。非阻塞主备份协议不保证所有备份服务器上的更新一致性。然而，它提高了性能。在主备份协议中，所有进程都将看到相同的写入操作顺序，因为此协议根据全局唯一时间对所有传入写入进行排序。阻塞协议保证进程查看上次写操作的结果。

主备份协议（本地写入）的示例

主备份协议（本地写入）的示例，要更新数据项，进程首先将其移动到其位置。结果，在该方法中，可以在本地执行连续的写操作，同时每个进程可以读取它们的数据项的本地副本。主数据库完成更新后，更新将转发到其他副本，并且所有副本都在本地执行更新。这种非阻塞方法可以带来改进。本地写协议的图表描述了基于主协议的本地写入方法。进程请求数据项x中的写操作。当前服务器被视为数据项x的新主要服务器。执行写操作，当请求完成时，主服务器向其他备份服务器发送更新请求。

三、 CAP-Availability（可用性）

3.1 可用性定义

每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。

3.2 可用性举例

一个一周里（168小时）有100小时可用的单元的可用性为100/168。可用性的值通常用小数来表示（如0.9998）。在高可用性的应用中，使用一个被称为几个九的度量，对应小数点后9的个数。在这个系统中，“五个九”相当于0.99999（或者99.999%）的可用性。

返回结果，是可用性的一个重要指标，他要求系统请求后，返回一个正常相应结果。正常的相应结果通常能够明确的反映出对请求的处理结果，即成功或失败。

四、 CAP-Partition tolerance（分区容错性）

分区容错性其实是约束了分布式系统需要具有如下的特性：分布式在遇到任何网络分区故障的时候，仍然需要保证对外提供满足一致性和可用性的服务，除非整个网络均已瘫痪。也就是说，它容忍错误的出现，在发生错误的情况下可以继续进行操作。

网络分区是指的在分布式系统当中，不同的节点分布在不同的子网络中，由于出现了一些故障导致自网络之间不能正常的进行连通，但是他们又是各自是正常的。这就导致了一种情况，整个网络变成了若干个孤立的区域。当然值得注意的是组成分布式系统的每个节点的进入和退出可以看作是一个特殊的网络区域。

五、CAP-爱恨情仇（为什么不能同时保证）

既然是分布式系统，我们来想象两个节点。如果说至少允许一个节点更新状态会导致数据不一致，那么这个时候就会导致“C-一致性”的缺失。如果要保证数据的一致性，那么将分区一侧的节点设置为不可用，那么就会导致“A-可用性”的丧失。那么如何保证A-C都可以呢？就是两个节点相互通信，然而这个时候就会导致P的丧失，而P又是不可或缺的，所以就导致了一个比较尴尬的事件的出现~~

六、CAP延伸版--BASE

架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。

（1）基本可用（Basically Available）

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。

电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

（2）软状态（ Soft State）

软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

（3）最终一致性（ Eventual Consistency）

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

后文BASE参考分布式系统的BASE理论。