一致性协议2PC与3PC详解

一致性协议详解

2PC与3PC

在分布式系统中，一个事务会发送给好几个相同服务器，每个服务器都各管各的，只能知道自己的事务操作结果，无法知道其他服务器的结果。

为了保持事务处理的ACID特性，就需要引入一个”协调者“组件来统一调度所有分布式节点的执行逻辑。

协调者来调度参与者的行为，并最终决定是否把事务真正进行提交。

2PC

二阶段提交协议是一种一致性协议，目前绝大部分的关系型数据库都是采用二阶段提交协议。

协议说明

阶段一：提交事务请求

1.事务询问

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

2.执行事务

各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中。

3.各参与者向协调者反馈事务询问的响应

如果参与者成功执行事务操作，那么反馈给协调者Yes响应，表示事务可以执行，反之表示不可以执行。

这阶段类似投票，即各参与者投票表明是否要继续执行接下去事务提交操作。

阶段二：执行事务提交

如果协调者之前从参与者得到的所有反馈都是yes，那么就会执行事务提交。

1.发送提交请求
协调者向所有参与节点发送Commit请求。

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

3.反馈事务提交结果

参与者反馈给协调者

4.完成事务
协调者接受到所有参与者反馈的Ack消息，完成事务。

中断事务

如果任何一个参与者向协调者反馈No响应，或者等待超时，协调者没有收到所有参与者反馈，那么就会中断事务。

1.发送回滚消息
协调者向所有的参与者节点发出Rollback请求。

2.事务回滚

参与者接收到Rollback请求后，会利用其在阶段一记录的Undo信息（要执行的事务的的反向操作）来执行事务回滚，回滚完后释放占用的资源。

3.反馈事务回滚结果

参与者完成事务回滚后，向协调者发送Ack消息。

4.中断事务

协调者接受到所有参与者反馈的Ack消息后，完成事务中断。

优缺点：

优点：简单，实现方便
缺点：同步阻塞，单点问题

同步阻塞：所有参与该事务操作的逻辑都处于阻塞操作，各个参与者都在等待其他参与者响应。

单点问题：协调者如果出现问题，那么整个事务提交都无法流转。更严重的是如果在二阶段出现问题，那么参与者将会一直处于锁定事务资源的状态中。

数据不一致：
在二阶段如果协调者只发送给部分参与者就奔溃了，那么剩下的参与者就无法进行事务提交，从而导致出现数据不一致现象。

太过保守：
只能靠超时机制来判断是否要中断事务。任意一个节点的失败都会导致整个事务的失败。

3PC

3PC是2PC的改进版，其将二阶段提交协议的”提交事务请求“过程一分为二，形成CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。

阶段一：CanCommit

1.事务询问
协调者向所有参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

2.各参与者向协调者反馈事务询问的响应。

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

阶段二：PreCommit

协调者根据所有参与者反馈情况来决定是否进行事务的PreCommit操作。

执行事务预提交

如果协调者从参与者得到的所有反馈都是yes，那么就会执行事务预提交。

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

2.事务预提交

参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记入事务日志中。

3.各参与者向协调者反馈事务执行的响应

如果参与者成功执行了事务操作，那么就会反馈给协调者Ack响应，同时等待最终的命令:提交（Commit）或中止（abort）。

中断事务：

如果任何一个参与者向协调者反馈No响应，或者等待超时，协调者没有收到所有参与者反馈，那么就会中断事务。

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

2.中断事务

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

阶段三

该阶段将进行正真的事务提交，会存在以下两种情况。

执行提交

1.发送提交请求

进入这一阶段，假设协调者处于正常工作状态，并且收到所有参与者Ack响应，那么它将从”预提交“状态转换到”提交“状态，并向所有的参与者发送doCommit请求。

2.事务提交

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

3.反馈事务提交结果

4.完成事务

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

中断事务

任意一个参与者向协调者反馈No响应，或者等待超时，就会中断事务。

进入阶段三，可能会存在以下两种故障

• 协调者出现问题
• 协调者和参与者之间的网络出现故障

无论那种情况，都会导致参与者无法及时接受来自协调者的doCommit或者abort，针对这种异常，参与者会在等待一段时间后，继续进行事务提交

优点：降低参与者的阻塞范围。

缺点：参与者接收到preCommit消息后，协调者如果挂了，那么参与者还是会进行事务提交，这会导致数据不一致问题。

参考：
《从Paxos到zookeeper分布式一致性原理与实践》