1. CAP 理论

任何分布式架构设计的系统，只能同时满足 CAP 中的任意两种，无法同时三种并存。
CAP（Consistency、Availability、Partition tolerance） 是三个单词的缩写，分别代表一致性，可用性，分区容错性。
这个理论到目前为止都适用于分布式架构系统。

1.1 Consistency 一致性

我们知道ACID中事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。
也就是说，事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。

举个例子：
A 转账 B ，A 扣款一百，B增加一百，这个是业务层级的一致性，连个业务都执行，才能保证最终一致性状态。

这种从刚开始的不变的状态，转变为另一种最终一致的状态，就是一致性。
分布式环境中的一致性是指数据在多个副本之间是否能够保持一致。这点应该不难理解，分布式集群架构中，有可能服务节点是多个，
这个时候我们就要考虑多个服务的情况下，读取的数据是否都能够一致，或者数据库集群中的数据是否都能够保证一致。

1. 强一致性

要求所有系统中的数据必须一致，不管谁先执行操作，都要等到其他系统数据更新完成才能继续执行下一步。
这点就会对性能有一部分影响，因为要确保所有节点的完全一致。

数据库为例，单库的数据肯定是一致的。多库情况下，其他节点的数据必须等到日志更新所有数据库完全后才能读取，这样才会保证数据的一致性。

1. 弱一致性 & 最终一致性

弱一致指数据更新后，不会立即要求所有的节点必须先同步，允许在一定时间后达到同步，这里面还有一种情况就是可能数据同步会失败，怎么办？
重试机制，失败了就再次尝试，直到最终达到一致性。

1.2 Availability 可用性

用户访问的服务会处在一种一直可用的集群状态，也就是服务高可用。能够保证一个请求在规定的有限时间返回结果。这里面还要考虑到服务
熔断、异常返回、服务降级（容错性）。这些都是微服务里面的重要概念。

1.3 Partition tolerance 分区容错性

容错性,那就是网络节点之间无法通信的情况下，节点被隔离，产生了网络分区， 整个系统仍然是可以工作的.
随着网络节点出现问题，产生了分区, 这时候其他节点和出错节点的数据必然会不一致，这时候就要面临选择，
是选择停掉所有的服务，等网络节点修复后恢复数据，以此来保证一致性（PC）,
还是选择继续提供服务，放弃强一致性的要求，以此来保证整体的可用性（PA）。

2 BASE 理论

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，

核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性
（Eventual Consitency）

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。
BASE理论是对CAP中一致性和可用性权衡的结果，是对大规模互联网系统分布式实践的总结。
BASE理论的核心思想是：即使无法做到强一致性，可以通过一些软状态和最终一致性的方式，来尽量达到一致性的要求。

2.1 基本可用

指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。那些情况属于这种基本可用呢？

1. 损失部分响应时间换取：

如果一个系统原本应该 10ms 内响应，但是现在可以允许出错后重试，可以规定重试N次，可能导致的结果就是时间变为 10*N，
或者通过网关转向可用的服务，这种情况比较乐观，可能不需要N次。

1. 损失部分非核心系统功能：

正常的，我们访问一个网站服务会返回我们想要的结果，但是如果后台服务发生了雪崩或者服务降级，我们也会有降级页面返回的处理结果，
当然对于客户可能不知道后台发生了什么，只是被引导到了降级页面并看到了立即返回结果，虽然结果不是我们想要的，但是保证了
基本响应。

2.2 软状态

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

2.3 最终一致性

最终一致性：各个节点的数据不一致，可以通过一系列的措施来进行更新补偿，最终达到一致性的要求。这个过程就是最终一致性。
强调的是要求最终一致，不需要实时保证系统数据的强一致。

求关注

程序领域