分布式一致性保证：两阶段提交、三阶段提交

分布式数据一致性

在分布式系统中，为了保证数据的高可用，通常会将数据保留多个副本，这些副本会放置在不同的物理机器上。

如果网络、服务器或者软件出现故障，就会导致部分副本写入成功。部分写入失败，这就造成各个副本之间的数据不一致。

CAP定理：一个分布式系统不可能同时满足一致性（C:Consistency）、可用性（A:Availability）和分区容错性（P:Partition tolerance）这三个基本要求，最多只能满足其中的两项。

BASE理论：Basically Available(基本可用）、Soft state(软状态）和Eventually consistent(最终一致性）三个短语的简写。BASE是对CAP中一致性和可用性权衡的结果，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方法来使系统达到最终一致性。

数据一致性模型

强一致性：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。根据 CAP 理论，这种实现需要牺牲可用性。

弱一致性：系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。

最终一致性：是弱一致性的一种特例。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。

两阶段提交

当一个事务跨多个节点时，为了保持事务的原子性与一致性，需要引入一个协调者（Coordinator）来统一掌控所有参与者（Participant）的操作结果，并指示它们是否要把操作结果进行真正的提交（commit）或者回滚（rollback）。

两阶段：

1、投票阶段：参与者将操作结果通知协调者；

2、提交阶段：收到参与者的通知后，协调者再向参与者发出通知，根据反馈情况决定各参与者是否要提交还是回滚；

两阶段执行：

1、投票阶段：

协调者发起一个提议（事务），并通知给所有参与者，然后进行投票。投票中参与者反馈给协调者自己的投票：同意执行或取消执行。

2、提交阶段

协调者基于第一阶段的投票结果进行决策：提交或取消。当且仅当所有参与者同意执行事务，协调者才会通知所有的参与者提交事务，否则协调组通知所有参与者取消事务。

两阶段提交缺点：

1、同步阻塞问题。执行过程中，所有参与者都是事务阻塞型的。

2、单点故障。只有协调者设置了超时时间，一旦协调者发生故障，参与者会一直阻塞下去。

3、数据不一致。阶段二中，当协调者向参与者发送commit请求后，发送局部网络异常，这会导致一部分参与者未接收到commit请求。

两阶段提交无法解决的问题：

协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

三阶段提交

与两阶段提交不同的是，三阶段提交有两个改动点。

1、同时在协调者和参与者中都引入超时机制。

2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

CanCommit阶段：

1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。

2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

PreCommit阶段：

两种情况，如果第一阶段反馈的都是Yes响应

1、协调者向参与者发送PreCommit请求，并进入Prepared阶段。

2、参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。

3、如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

如果第一阶段反馈的不全是Yes响应

1.发送中断请求 协调者向所有参与者发送abort请求。

2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

doCommit阶段：

两种情况，如果协调者收到所有ACK响应

1、所有参与者发送doCommit请求。

2、参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。

3、事务提交完之后，向协调者发送Ack响应。

4、协调者接收到所有参与者的ack响应之后，完成事务。

协调者没有接收到所有参与者的ACK响应（可能是中断响应或超时）

1、协调者向所有参与者发送abort请求

2、参与者接收到abort请求之后，利用其在阶段二记录的undo信息来 执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

3、参与者完成事务回滚之后，向协调者发送ACK消息

4、协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

小结：

1、3PC中，协调者和参与者都设置了超时时间。

2、在doCommit中，如果参与者没有收到协调者的最终提交请求超时后，会自动认为可提交，并正式提交事务。（可能会造成数据一致性问题）

相对于2PC，3PC协调者和参与者都设置的超时时间（2PC中只有协调者有超时时间），主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit，而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作，这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。