CAP、BASE、2PC理论

CAP

• Consistency(一致性)：指数据在多个副本之间能够保持一致的特性（严格的一致性）
• Availablility(可用性)：指系统提供的服务必须一直处于可用状态，每次请求都能获取的数据为最新数据）
• Partition tolerance(分区容忍性)：分布式系统在遇到任何网络分区故障时，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

BASE

• 基本可用（Basically Available)
• 软状态（Soft State)
• 最终一致性（Eventually Consistent)

基本可用

假设系统出现了不可预知的故障，但还是能用，相比正常的系统而言：

1. 响应时间上的损失：着呢刚才情况下搜索引擎0.5秒及返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
2. 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态

相对于原子性而言，要求多个节点的数据副本都是一致的，这是一个“硬状态”。

软状态指的是：允许系统中的而数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同的节点的数据副本存在数据延时。。

最终一致性

上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

而在实际工程实践中，最终一致性分为5种：

1. 因果一致性（Causal consistency）

因果一致性指的是：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。

2. 读己之所写（Read your writes）

读己之所写指的是：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。

3. 会话一致性（Session consistency）

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

4. 单调读一致性（Monotonic read consistency）

单调读一致性指的是：如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

6. 单调写一致性（Monotonic write consistency）
   .
   单调写一致性指的是：一个系统要能够保证来自同一个节点的写操作被顺序的执行。

---

在实际的实践中，这5种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。

实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。

2PC(两阶段提交)

定义

两阶段提交的算法思路可以概括为：每个参与者将操作成功或失败通知给协调者，再有协调者根据所有参与者的反馈情报，决定个参与者是否要提交操作还是终止操作。

所谓的两个阶段分别是：

• 第一个阶段：准备阶段（投票阶段）
• 第二个阶段：提交阶段（执行阶段）

准备阶段

三步骤：

1，事务询问
	协调者向所有的参与者询问，是否准备好了执行事务，并开始等待各个参与者的响应
2，执行事务
	各参与节点执行事务操作，入宫本地事务成功，将Undo和Redo信息记入事务日志中，但不提交；否则，直接返回失败，退出执行。
3，各个参与者向协调者反馈事务询问的响应
	如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行提价；
	如果参与者没有成功执行事务，那就返回No给协调者，表示不可以执行提交。		

提交阶段

在提交阶段中，会根据准备阶段的投票结果执行2种操作：执行事务提交，中断事务。

提交事务过程如下：

1. 发送提交请求
协调者向所有参与者发出commit请求。

2. 事务提交
参与者收到commit请求后，会正式执行事务提交操作，
并在完成提交之后，释放整个事务执行期间占用的事务资源。

3. 反馈事务提交结果
参与者在完成事务提交之后，向协调者发送Ack信息。

4. 事务提交确认
协调者接收到所有参与者反馈的Ack信息后，完成事务。

中断事务过程如下：

a. 发送回滚请求
协调者向所有参与者发出Rollback请求。

b. 事务回滚
参与者接收到Rollback请求后，会利用其在提交阶段种记录的Undo信息，来执行事务回滚操作。
在完成回滚之后，释放在整个事务执行期间占用的资源。

c. 反馈事务回滚结果
参与者在完成事务回滚之后，想协调者发送Ack信息。

d. 事务中断确认
协调者接收到所有参与者反馈的Ack信息后，完成事务中断。

二阶段提交的优缺点

优点：原理简单，实现方便。
缺点：同步阻塞，单点问题，数据不一致，容错性不好。

同步阻塞

在二阶段提交的过程中，所有的节点都在等待其他节点的响应，无法进行其他操作。
这种同步阻塞极大的限制了分布式系统的性能。

单点问题

协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转。
更重要的是，其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。

数据不一致

假设当协调者向所有的参与者发送commit请求之后，发生了局部网络异常，
或者是协调者在尚未发送完所有 commit请求之前自身发生了崩溃，
导致最终只有部分参与者收到了commit请求。这将导致严重的数据不一致问题。

容错性不好

如果在二阶段提交的提交询问阶段中，参与者出现故障，导致协调者始终无法
获取到所有参与者的确认信息，这时协调者只能依靠其自身的超时机制，判断是否需要中断事务。
显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，
任意一个节点是失败都会导致整个事务的失败。