分布式系统基础理论

CAP是分布式系统方向中的一个非常重要的理论，可以粗略的将它看成是分布式系统的起点，CAP分别代表的是分布式系统中的三种性质，分别是Consistency（可用性）、Availability（一致性）、Partition tolerance（网络分区容忍性），它们的第一个字母分别是C A P，于是这个理论被称为CAP理论

理论上来说，CAP三者同时最多满足两者，但是并不是必须满足两个，许多系统最多只能同时满足0、1个

为什么CAP最多只能满足两个呢?

我们可以以电商系统的两个集群来当做例子

C: 追求的是数据一致性 当有一个请求来了之后 它会等待网络隔离的情况结束之后 向另一个机器进行数据的同步

A: 追求的是可用性 也就是尽可能提供有效服务 当一个请求来了之后 它会立即返回 哪怕数据是陈旧的 也得优先提供服务，其他分区的节点返回的结果（数据）可能是不一样

注意：这里的AP不可同时满足指的是当整个分布式系统中出现网络隔离的时候，我们不能既想着保证数据的实时强一致性，又去追求服务的可用性。

但是当没有网络隔离的时候，其实这两个性质是可以同时满足的，因为『同步数据』和『返回结果』这两个操作都是在同一个网络中，只有先后关系，不会因为某个操作导致另一个操作的『死等』

在分布式系统中，P是会必然发生的，造成P的原因可能是网络隔离，也可能是节点宕机。

我们无法保证分布式系统每一时刻都不出现网络隔离，如果不满足P的特性，一旦发生分区错误，那么分布式系统就无法工作，这显然违背了分布式的理念，连最基本的分布式系统条件都没有满足

典型的CP和AP的产品

CP：Zookeeper 当系统在发生分区故障之后 客户端的所有请求都会被卡死或者超时 但是系统总会返回一致的数据

AP：Eureka 分区发生故障之后 客户端依然可以访问系统 但是获取的数据有的是新数据 有的是老数据

当然 CAP这几个特性不是BOOL类型的，而是一个范围类型，完全是看系统具体需要什么样的要求。

比如分区容错，有的系统一台机器出错，系统会认为不影响业务的话，认为分区不存在。只有多台机器都出问题了，系统受到严重影响才认为出现分区

PACELC理论
PACELC理论是对CAP理论的扩展，在维基百科上的定义是

It states that in case of network partitioning § in a distributed computer system, one has to choose between availability (A) and consistency © (as per the CAP theorem), but else (E), even when the system is running normally in the absence of partitions, one has to choose between latency (L) and consistency ©.

如果有分区（P），那么系统就必须在可用性（A）和一致性（C）之间取得平衡，否则（E），当系统运行在无分区的情况下，系统需要在延迟（L）和一致性（C）之间取得平衡

它相比于CAP，多引入了一个延迟Latency的概念，在出现分区错误的时候，取前半部分PAC，理论和CAP的内容一致。没有出现分区错误的时候取LC，也就是Latency与Consistency

当前分布式系统指导理论更替代CAP理论，理由如下

PACELC更能满足实际操作中分布式系统的工作场景，是更好的工程实现策略
当P存在的场景下，需要在A C之间做取舍，但是实际上分布式系统大部分时间里P是不存在的，那么在L和C之间做取舍是一个更好的选择
PACELC可以在latency与consistency之间获得平衡
要保证系统的高可用，那么就得采用冗余的思想，我的其他博文有提到4个9的异地多活策略，也是采用的数据冗余思想，而一旦涉及到了复制数据，在分布式中就一定会在Consistency和Latency之间做一个取舍
image.png
举个例子

在强一致性的场景下，需要三个从节点都落盘数据，才能给客户端返回OK，这个时候当master向slave同步数据的时候，超过20ms触发超时了，整个系统还是会不断的重试这个过程，这显然造成了系统的可用性比较低
所以我们一般都会在数据一致性和请求时延之间做一个balance

当同步超过五次之后，认为这个节点故障，选择直接返回，可以消除写时的长尾抖动，同时给节点打上故障标签，进行后续的处理

BASE理论
base理论是Basically Avaliable(基本可用)、Soft State（软状态）、Eventually Consistent（最终一致性）三个短语的缩写，核心思想如下

即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性

BA：基本可用指的是当系统出现了不可预知的故障，系统依旧可用，不过可用度也许会降低，比如响应时间上出现损失，功能上只能满足基本功能等等

S：基于原子性而言的话，当要求多个节点数据一致时，我们认为这是一种『硬』状态，而允许系统中的数据存在中间状态，并认为其不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据时延

E：最终一致性，系统不可能一直都处于一个软状态中，必须有个时间期限。在期限过后，应该保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于时延、负载、方案等等

在工程实践中，有这么几种最终一致性的实现策略，通常都是多种策略混合实现

因果一致性：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。与此同时，与节点A无因果关系的节点C的数据访问没有这样的限制
读已知所写：节点A更新一个数据之后，自身总是能访问到更新过的最新值，而不会访问旧值
会话一致性：将对系统数据的访问过程框定在了一个会话当中，系统能保证同一个有效的会话中实现客户端在一个会话中读取到该数据项永远是最新值
单调读一致性：如果一个节点从系统中读取出一个数据项的某个值之后，那么系统对于该节点后续的任何数据访问都不该返回更旧的值
单调写一致性：一个系统要能够保证来自同一个节点的写操作被顺序的执行。