一致性协议

2PC和3PC

2PC(Two-Phare Commit)

阶段一：提交事务请求

　　1 - 事务询问  协调者像所有参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

　　2 - 执行事务  各参与者执行事务，并记录Undo和Redo信息（Undo和Redo是数据库用来commit和rollback的记录文件）

　　3 - 各参与者向协调者反馈事务询问的响应  如果参与者事务执行成功，则返回给协调者yes，否则返回给协调者no

阶段二：执行事务提交

　　1 - 执行事务提交（所有的参与者均返回yes）

　　　　1 - 发送提交请求  协调者向所有参与者发送提交请求

　　　　2 - 事务提交  参与者接收到协调者发出的请求后，完成自己的事务提交，并在提交完成后释放这个事务执行期间占据的资源

　　　　3 - 反馈事务提交结果  参与者在完成事务后，像协调者发送Ack消息

　　　　4 - 完成事务  协调者接收到所有参与者返回的Ack消息，完成整个分布式事务

　　2 - 执行事务回滚（非所有参与者均返回yes）

　　　　1 - 发送回滚请求  协调者向所有参与者发送rollback请求

　　　　2 - 事务回滚  参与者接收到协调者发出的请求后，完成自己的事务回滚，并在提交完成后释放这个事务执行期间占据的资源

　　　　3 - 反馈事务回滚结果  参与者在完成各自的事务回滚后，向协调者发送Ack消息

　　　　4 - 中断事务（回滚事务）  协调者接收到所有参与者返回的Ack消息后，完成分布式事务的回滚

 

2PC的优缺点

优点：原理简单，实现方便

缺点：同步阻塞，单点问题，脑裂，数据不一致，太过保守

 

3PC（Three-Phare Commit）

阶段一（CanCommit）：

　　1 - 事务询问：协调者询问各参与者是否可以开始事务，并开始恩待各参与者的响应

　　2 - 各参与者回复协调者反馈事务询问的请求：参与者如果可以执行事务，返回yes,否则返回no

阶段二（PreCommit）

　　1 - 执行事务预提交：所有参与者均返回yes

　　　　1 - 发送预提交请求：协调者向所有参与者发出preCommit请求，并进入Prepared阶段

　　　　2 - 事务预提交：参与者接到preCommit请求后，会执行当前事务，并记录Undo和Redo信息

　　　　3 - 各参与者向协调者反馈事务预提交的情况：如果参与者成功执行了事务操作，那么就会返回给协调者Ack响应

　　2 - 中断事务（分布式事务回滚）

　　　　1 - 发送中断请求：协调者向所有的参与者发送abort请求

　　　　2 - 中断事务：无论是收到来自协调者的abort请求，或者是在等待协调者请求过程中出现超时，参与者都会中断事务

阶段三（doCommit）

　　1 - 执行提交

　　　　1 - 发送提交请求：协调者接收到了所有参与者在阶段二返回的Ack响应，那么它将会从"预提交"状态变成"提交"状态，并向所有的参与者发送doCommit请求

　　　　2 - 事务提交：参与者接收到协调者发出的doCommit请求后，会将自己的事务正式提交，并在完成之后释放整个事务执行期间占用的事务资源

　　　　3 - 反馈事务提交结果：各参与者将自己的事务提交后，会向协调者发送Ack消息

　　　　4 - 完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务

　　2 - 中断事务（）

　　　　1 - 协调者发送中断请求：协调者向所有的参与者发送abort请求

　　　　2 - 事务回滚：参与者在接收到协调者发出的abort请求后，会利用之前记录的Undo信息执行事务回滚，并在成功回滚后释放事务执行期间占用的资源

　　　　3 - 返回事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息

　　　　4 - 中断事务：协调者在接收到所有参与者返回的Ack消息后，中断事务。

当协调者出现问题

或者参与者和协调者直接的网络出现问题

无论哪种情况，都会导致参与者无法及时接受到来自协调者发送的doCommit请求或者abort请求，针对这样的情况，参与者会在等待超时之后，继续进行事务提交。

 

优缺点：

1 - 相对于2PC，降低了参与者的阻塞范围，因为有阶段一。在阶段一就能确定是否可以执行事务。当部分参与者在阶段一表示无法正常开启事务时，是不会让其他参与者阻塞的，而不是像2PC那样上来直接开启事务，让所有参与者都处于阻塞状态

2 - 在单点故障后还能达成一致。引入超时处理，当单点故障后，参与者会自己回滚

 

缺点:

在协调者向所有参与者发送doCommit请求时，协调者和部分参与者之间的网络出现问题，导致部分参与者接收到doCommit请求，部分参与者没有接收到。接收到doCommit请求的参与者完成了自己的事务，没有接收到doCommit请求的参与者在超时之后将之前预提交的事务回滚，从而导致整个系统的数据不一致。