CAP 理论
2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP 理论正式成为分布式计算领域的公认定理。
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
但是在真实环境中，网络是不可能做到100%可靠的，所以，对于一个分布式系统来说，P 是一个基本要求，CAP 三者中，只能在 CA 两者之间做权衡，并且要想尽办法提升 P。
BASE 理论
2008年，eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结，在 ACM 上发表文章提出 BASE 理论，BASE 理论是对 CAP 理论的延伸，是对 CAP 中一致性和可用性权衡的结果，核心思想是即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual Consitency）。
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE 理论允许不同节点之间的数据同步存在延时，降低一定的可用性要求，但数据要达到最终一致。
一致性是分布式理论中的根本性问题，在分布式系统中，进行数据库事务提交(commit transaction)、Leader 选举、序列号生成等都会遇到一致性问题。为了在相互独立的节点之间达成一项统一的决议，保证数据的高可用，在长期的研究探索过程中，业界涌现出了许多典型的理论协议和算法。下面我们从特定条件下解决一致性问题的两种方法(2PC、3PC)入门，了解最基础的分布式系统理论。
二阶段提交协议（2PC）
2PC(two phase commit) 顾名思义分成两个阶段，先由一方进行提议(propose)并收集其他节点的反馈(vote)，再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants)。
改进
相比一次性提交，分两步可以让事务先执行然后再提交，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶段将耗时极短，耗时极短意味着操作失败的可能性也就降低。
缺陷
同步阻塞
整个过程中，所有参与节点都是事务阻塞型的，都在等待其他节点的响应，无法进行其他操作。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态，这种同步阻塞极大的限制了分布式系统的性能。单点故障
协调者是整个提交过程的核心，一旦协调者发生故障，参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。尽管协调者挂掉后可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题。数据不一致
在 P2A 阶段，当协调者向参与者发送 commit 请求之后，发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障，这会导致只有一部分参与者接受到 commit 请求。参与者接到 commit 请求之后就会执行 commit 操作，但是其他部分未接到 commit 请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据不一致性的问题。容错性差
如果在二阶段提交的提交询问阶段中，参与者出现故障，导致协调者始终无法获取到所有参与者的确认信息，这时协调者只能依靠其自身的超时机制，判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。
三阶段提交（3PC）
3PC 是 2PC 的改进版本，在两阶段提交的基础上增加了 CanCommit 阶段，并引入了超时机制。
改进
减少阻塞
第一阶段 canCommit 并不执行事务，这样当第一阶段失败或者 timeout 时，不占用事务资源不需要回滚(提高效率减少事务阻塞)。参与者返回 PreCommit 请求的响应后，等待第三阶段指令，若等待超时，则自动 commit 事务，也降低了阻塞。引入超时机制
在 2PC 中，只有协调者拥有超时机制，3PC 同时在协调者和参与者中都引入超时机制， 主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后主动提交释放资源，降低了阻塞时间。参与者返回 CanCommit 请求的响应后，等待第二阶段指令时，若协调者宕机，等待超时后自动 abort。由于有第一阶段 canCommit 的 yes 才会进入第三阶段，因而该阶段极大概率是 commit 而不是 rollback，当第三阶段开始前协调者挂掉，参与者等待超时后默认执行 commit 是最接近正确的行为。
缺陷
和 2PC 一样，3PC 还是可能会存在不一致性问题，比如第三阶段协调者发出了 abort 请求，这时网络故障，有些参与者没有收到 abort，那么就会自动 commit，造成数据不一致，因而适合本地(无网络情况)或者网络非常好的情况。
小结
可以看到，无论是 2PC 还是 3PC 都没有完美解决分布式系统中的一致性问题，但是它们原理简单、实现方便，对业务的侵入性小，在低并发、网络稳定、规模有限的特定场景下，能够严格保障分布式系统的强一致性，所以在关系型数据库的分布式事务、大数据流式计算中的 exactly once 语义下都有很好地运用。
