1、CAP的延伸BASE理论：
对于BASE理论：BASE理论是牺牲强一致性的情况，就是说，选择AP，舍弃C，对于C只做到最终一致性，存在着基本可用，（对于部分用户请求服务进行降级，损失部分可用，保证核心可用性）。软状态（允许分布式系统存在中间状态，不同系统数据存储副本同步就是软状态），最终一致性（经过一定的时间，系统中所有副本都能达到最终一致性）。
2、二阶段提交协议，三阶段提交协议：
分布式一致性的回顾：
为了保证数据的高可用，通常我们会将数据保留多个副本，这些副本放置在不同的物理机上为了对用户提供正确的增删改查，我们需要保证这些副本放置在不同物理机上是一致性的。
分布式事务的说明：
这里提醒一点，区分，数据库事务和分布式事务的区别：
从范围上讲：分布式事务更大，涉及到多个数据库，而数据库事务只涉及到一个数据库。要想让分布式数据达到一致性，就要保证所有节点的数据写操作要么全部都执行，要么全部都不执行。但是一台机器上执行本地事务无法知道其它机器中的本地事务的执行结果，于是引入一个”协调者“组件来统一调度所有的分布式节点的执行。
XA规范，定义了分布式事物的处理模型。
二阶段提交和三阶段提交就是根据这一思想产生的，或者说，二阶段提交就是XA分布式事务的关键或者说，二阶段提交主要保证了分布式事务的原子性：即所有节点，要么全部做，要么全部不做。
2PC:
**概念：**在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。
**二阶段提交的算法思路是：**参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各个参与者是否要提交操作或者中止操作。
第一阶段：准备阶段（投票阶段）第二阶段： 提交阶段（执行阶段）
准备阶段：
事务协调者（事务管理器）给每个参与者（资源管理器）发送Prepare消息，每个参与者要么直接返回失败（如权限验证失败）向事务协调者返回 ”中止“，要么执行事务写redo和undo日志，但不提交，并向事务协调者返回 ”同意“消息。
提交阶段：
如果第一阶段协调者收到了任何一个参与者失败消息或者超时，直接返回给每个参与者发送回滚消息。
如果第一阶段协调者受到的参与者消息全是成功的消息，这时，协调器给每个参与者发送提交消息。
然后在最后阶段，释放所有事务在处理过程中使用的锁资源。
模拟协调者发送提交的请求：
1）协调者节点向所有参与者节点发出“正式提交”的请求
2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源
3）参与者节点向协调器发送“完成”消息
4）协调者节点收到参与者节点的反馈“完成‘消息结束事务
协调者无论是去发送正式提交还是回滚操作，第二阶段都会结束事务。
2PC存在的问题：
1）阻塞问题：一个参与者一旦占用公共资源，其它参与者如果去获取这些资源会阻塞着
2）单点故障：一旦协调者发生了故障，参与者就会阻塞，即使重新选出来了协调者但还是无法改变参与者阻塞的问题。
3）数据不一致性：在向参与者发送commit请求后，协调者发生故障或者局域网异常，就会导致参与者数据不一致的状态
4）二阶段无法解决的问题：发送完commit消息后，协调者宕机了，参与者也宕机了。
由于2PC这么多问题所以3PC提交产生了：
3PC :
在二阶段的基础上改动两点：
1、引入超时机制，协调者和参与者均有超时机制
2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各个参与节点的状态是一致的。其实这里，是把二阶段提交中的准备阶段一分为二去执行，CanCommit首先去询问是否可以提交事务，然后执行PreCommit，执行事务操作，并把undo和redo信息记录到事务日志中。第三阶段是doCommit
CanCommit阶段：
1、事务询问：协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始参与者的响应。
2、响应反馈：参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes，并进入预备状态，否则反馈No
PreCommit阶段：
如果CanCommit返回的是Yes响应，1、发送预提交请求：协调者向参与者发送PreCommit请求，并进入Prepare阶段。
2、事务预提交：参与者接收到PreCommit请求后，后执行事务操作，并将undo和redo记录信息记录到事务日志中
3、响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应，同时开发等待最终的指令。
。。。。。。下边的就不写了，套路一样。
虽然3PC阶段解决了单点故障问题，并减少了阻塞，因为一旦无法及时收到来自协调者的信息之后，他会默认执行commit，而不会一直持有事务资源并处于阻塞状态。但是因为网络原因，仍然会发生数据不一致的可能，所以，世界上只有一种一致性算法，就是Paxos。
