浅谈分布式一致性协议之2PC

最新推荐文章于 2022-11-14 17:07:30 发布

wh柒八九

最新推荐文章于 2022-11-14 17:07:30 发布

阅读量863

点赞数 2

分类专栏：核心知识点分布式文章标签：分布式算法

本文链接：https://blog.csdn.net/qq_31960623/article/details/116405742

版权

核心知识点同时被 2 个专栏收录

559 篇文章 89 订阅

订阅专栏

分布式

44 篇文章 10 订阅

订阅专栏

由于BASE理论需要在一致性和可用性方面做出权衡，因此涌现了很多关于一致性的算法和协议。其中比较著名的有二阶提交协议（2 Phase Commitment Protocol），三阶提交协议（3 Phase Commitment Protocol）和Paxos算法。

前言

前面一篇文章和大家一起学习了下分布式系统一致性问题的一些理论，其中重点是理解PACELC理论、BASE理论等问题，让我们对于分布式一致性的重点是什么有一些认识。在了解分布式一致性的理论和概念之后，后续将和大家一起讨论分布式一致性协议，其中包括：2PC、3PC、Paoxs协议、Raft协议。篇幅有限，本文重点展开2PC协议，后续文章继续深入。

单机事务和分布式事务

在聊2PC和3PC之前，我们有必要先了解下单机事务和分布式事务。事务是一组原子操作，要么全成功要么全失败 All or Nothing，否则就会出现数据混乱，这种需求在金融和电商领域很普遍。试想你去天猫买了台mac，订单服务、扣款服务、库存服务出现任何一个环节的失败都会带来问题，所以就需要事务来做保证，一荣俱荣一损俱损。

在这里插入图片描述
单机事务具备ACID特性，大家都比较喜欢，但是单机的能力毕竟有限，我们常常必须在分布式场景下同样完成这一组原子操作，也就是分布式事务。

由于分布式系统中各个子服务是部署在不同的物理节点上，不同交换机、不同机房、不同城市，这样以来，要想像单机系统一样完成这一组原子操作就没那么容易了，因此就出现了很多分布式一致性协议和算法，来解决分布式事务问题保证数据一致性。

分布式系统的各个节点只能依靠网络来进行数据通信，但是网络往往并不完全可靠，同时节点物理故障也时常发生，在这样一个复杂的环境中去保证数据一致性确实不太容易。

在这里插入图片描述

一致性协议的一些思路

突兀地去学习一个新的协议或者算法往往比较生硬，不如思考一下生活现象，大部分的计算机领域的算法和思想在实际生活中都有映像，又或者说算法来源于生活。

举个栗子：在规模盛大的阅兵仪式中会有陆海空多兵种多方队，为了让命令和节奏准确地下达，我们需要乐曲、指挥、领队、排头、队员等多种角色。整个活动需要在不同角色的相互作用之下，才能让一个数量庞大的个体组成一个整体来完成一个目标。

再举个栗子：2018年5月在西安举行了一场盛大的无人机编组飞行灯光秀，共计1374架无人机组成一个庞大的编组来完成灯光表演，但是还是出现了问题，并未上演完美图案：

在这里插入图片描述

分布式系统也是如此，为了让很多参与的机器节点节奏步调一致，我们就需要不同的角色各司其职，共同完成一项任务，但是仍然困难重重，因为会有网络故障和节点物理故障等问题。

2PC二阶段提交协议基本过程

要理解2PC协议重点在于节点角色分工和两个阶段所执行的动作以及不同情况下的处理逻辑。

两阶段提交又称2PC,2PC是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。

在这里插入图片描述
2PC协议总体概览

节点角色

二阶段提交协议将节点分为：协调者和参与者，对于者两种角色，当然你也可以理解为Leader和大头兵。

协调者Leader，负责向参与者发送指令，收集参与者反馈，做出提交或者回滚决策
参与者大头兵，接收协调者的指令执行事务操作，向协调者反馈操作结果，并继续执行协调者发送的最终指令

两个阶段

2PC协议分为：准备阶段和提交阶段。

准备阶段

协调者向所有参与者节点发送询问并执行事务的命令，参与者节点收到命令后根据自己的状态执行或者不执行事务，并将动作记录下来，最后将对命令的处理结果反馈给协调者。

在这里插入图片描述
准备阶段的三个环节

1询问环节：协调者向参与者询问，是否准备好可以执行事务，之后协调者开始等待各参与者的响应，这个环节协调者处于阻塞等待状态。

2处理环节：参与者收到协调者的询问后根据自身情况来决定是否执行事务操作，如果参与者执行事务成功，将Undo和Redo信息记入事务日志，但不提交事务；否则直接返回失败。

3响应环节：当参与者成功执行了事务操作，就反馈yes给协调者，表示事务在本地执行；当参与者没有成功执行事务，就反馈no给协调者，表示事务不可以执行提交，这部分反馈对于协调者决策下个阶段起到非常重要的作用。

提交阶段

协调者根据准备阶段收到的参与者反馈来决定最终提交事务或者中断回滚事务，具体来说，当协调者在准备阶段结束时收到的响应反馈有一个no，那么就中断事务，如果收到的反馈全部是yes就提交事务。

情况一: 提交事务

如果在准备阶段结束时，协调者收到了来自所有参与者的yes反馈，接下来协调者就会向所有参与者发送提交事务指令，具体的过程如下：

在这里插入图片描述

步骤1. 协调者向所有参与者发送事务提交消息Commit命令

步骤2. 参与者在收到来自协调者的Commit命令之后，执行事务提交动作，并释放事务期间所有持有的锁和资源，这一步很重要

步骤3. 所有参与者在执行本地事务且释放资源完成后，向协调者发送事务提交确认消息ACK

步骤4. 协调者在收到所有参与者的ACK消息后确认完成本次事务

情况二: 回滚事务

如果在准备阶段结束时，协调者没有收到来自所有参与者的yes反馈，接下来协调者就会向所有参与者发送回滚事务指令，具体的过程如下：

在这里插入图片描述

步骤1. 协调者向所有参与者发送事务回滚消息Rollback

步骤2. 参与者收到Rollback回滚指令后，根据本地的回滚日志来撤销阶段一执行的事务，并释放事务期间所有持有的锁和资源

步骤3. 所有参与者在完成指令后向协调者回复反馈ACK

步骤4. 协调者在收到所有参与者的ACK确认消息后撤销该事务

通过上面的描述我们知道了，2PC协议通过将节点分为不同的角色，进行两个阶段的处理来执行分布式事务，但是难免要去想2PC协议可以真正解决分布式数据一致问题吗？

2PC协议的异常分析

前面的两个阶段涉及了多次协调者和参与者的网络通信交互，但是我们都知道网络是不可靠的，节点也能出现故障，因此必须要考虑异常情况下2PC协议是否仍然可以正常工作。

故障可以分为很多种：可恢复机器故障和不可恢复机器故障、网络正常抖动故障、网络分区故障等多种情况。

2PC整个过程交互也很多，不同阶段发生不同故障造成的结果也是不一样的，显然这是个m*n的组合问题，不同的异常情况会产生不同的结果要完全列出来并分析绝非易事，我们找其中几个重点异常来做分析。

从前面的分析我们知道，在准备阶段本质上是不会提交事务数据的，即使发生故障也可以根据日志来进行回滚，所以不会产生数据不一致的问题，但是在提交阶段提交事务的情况下由于可能已经有参与者提交了事务数据，因此可能出现数据不一致，这个是要重点分析的阶段。

在这里插入图片描述
注：以下所说的参与者故障并非指全部的参与者，而是其中1个或者几个。

协调者故障&参与者正常

协调者作为系统的领导者角色，由于协调者是单点的在任何过程出现异常都需要重点处理，发生不可恢复的物理故障时，选举出新的协调者来接替之前的工作，这时新协调者就需要向所有参与者询问当前的阶段和处理进度，但是如果只是出现网络分区协调者暂时失联，就可能出现脑裂的情况。

协调者正常&参与者故障

由于协调者做决策需要依据参与者的反馈，出现参与者故障会造成协调者决策困难，如果参与者的故障是可恢复的，在短时间内恢复后则向协调者询问自己需要做什么，从而跟上节奏，如果时间过长或者是不可恢复故障，那么协调者就会回滚本次事务。

协调者故障&参与者故障(重点)

协调者在提交阶段会向所有参与者发送指令，假定在协调者发送第一条指令之后挂掉，此时只有一个参与者接收到了指令并执行后也挂掉了，其他参与者并没有收到指令。新选举出来的协调者询问所有参与节点状态时，如果已经挂掉的参与者恢复了，那么状态就明确了commit或者rollback，如果挂掉的参与者并没有恢复并且已经执行了commit/rollback操作，那么将会出现数据不一致，并且新的协调者由于没有获得足够的信息无法明确当前的状态，其他的参与者在阶段一执行后产生阻塞。