其实很重要的一个分布式理论基础3pc协议

在之前的文章中我曾介绍了2pc协议的相关知识，这篇文章开始介绍3pc协议。理论知识往往是枯燥无味的，但是等学完了技术再回过头来重新认识的时候，你会有不一样的收获。这个点是面试常问的点，而且如果你正在对java技术或者是其他的技术进阶学习的话，这个知识点也是应该要掌握的。

CAP理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。比如下面这张图：

在这三项当中AP在实际应用中较多，它舍弃了一致性。为什么要舍弃一致性呢？就好比是我们在买火车票的时候，明明看到还有一张票，可是等我选好了座位准备付钱的时候，系统却提示没票了。这就是舍弃了一致性，数据可能是不一致的。但是分区容错性和可用性却得到了满足。

但这不是说一致性不重要，相反恰恰它是最重要的。我们再举个例子，在我们的银行系统中就必须要求数据的一致性，道理你也能明白，对我们来说，我们舍弃的只是强一致性。但是一定要满足最终一致性。也就是说，但是最终也要将数据同步成功来保证数据一致。

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展。从上图我们已经能够看出了。

为了实现 BASE 理论，需要在可用性和一致性之间找到一个合适的一致性理论，之前曾经使用过2pc协议，但是这种协议过于保守，会出现很多的问题，因此为了解决2pc协议的缺陷，出现了3pc协议。

我们首先来看一下2pc协议是如何保证最终一致性的。

也就是说2pc协议主要分为两个阶段：

（1）提交事务请求

（2）执行事务提交

现在我们使用3pc协议来更改一下看看：

也就是说，3PC 将阶段一 "提交事务请求" 分成了2部分，总共形成了 3 个部分：

（1）CanCommit

（2）PreCommit

（3）do Commit

阶段一：CanCommit

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

（2）各参与者向协调者反馈事务询问的响应，如果参与者认为自己可以顺利执行事务，就返回 Yes，否则反馈 No 响应。

阶段二：PreCommit

协调者在得到所有参与者的响应之后，会根据结果执行2种操作：执行事务预提交，或者中断事务。

（1）执行事务预提交：

首先协调者向所有参与者节点发出 preCommit 的请求，并等待响应。然后参与者受到 preCommit 请求后，会执行事务操作，并将结果返回。最后协调者得到了Ack响应，确定下一阶段是否为提交或者是终止操作。

（2）中断事务也分为2个步骤：

首先协调者向所有参与者节点发出 abort 请求。然后参与者如果收到 abort 请求或者超时了，都会中断事务。

阶段三：do Commit

（1）执行提交

首先协调者发送提交请求，并等待Ack 响应。然后参与者收到 doCommit 请求后，执行事务并反馈事务提交结果，向协调者发送 Ack 消息。最后协调者接收 Ack 消息后，完成事务。

（2）中断事务

中断事务是因为出现了异常，比如协调者一方出现了问题，或者是协调者与参与者之间出现了故障。

首先协调者向所有的参与者发送中断请求。然后参与者接收到中断请求后，会利用其在二阶段记录的 undo 信息来执行事务回滚操作，并释放资源。接下来参与者在完成事务回滚之后，向协调者发送 Ack 消息。最后协调者接收到所有的 Ack 消息后，中断事务。

3PC对于协调者和参与者都设置了超时时间，而2PC只有协调者才拥有超时机制。这个优化点，避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题。

而且3pc多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。

更多相关文章