分布式事务与分布式系统

2401_85766992

于 2024-06-19 00:50:23 发布

阅读量472

点赞数 21

文章标签：分布式

本文链接：https://blog.csdn.net/2401_85766992/article/details/139787138

版权

第一阶段预处理阶段：事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息，每个参与者要么直接返回失败，要么在本地执行事务，写本地的 redo 和 undo 日志，但不提交。其预处理要分为三个子步骤：
协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。
参与者节点执行询问发起为止的所有事务操作，并将 Undo 信息和 Redo 信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。
第二阶段提交阶段：如果协调者收到了参与者的失败或超时，直接给每个参与者发送回滚(rollback)操作；否则发送提交(commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。

无论最后结果如何，第二阶段都结束当前事务。

两阶段有如下几个缺点：

同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。在第一阶段，做预处理时会锁住对应的资源，到第二阶段收到协调者发送的 commit 或者 rollback 消息才释放锁资源,则协调者发送回滚操作才释放锁资源。在锁资源到释放资源过程，会阻塞第三方节点访问该锁资源。
单点故障。由于协调者的重要性，一旦协调者发生故障，则无法继续完成事务操作。
数据不一致。在第二阶段中，当协调者向发送 commit 消息请求之后，发生了局部网络异常或者发送 commit 请求过程中协调者发生了故障，会出现部分参与者接收到 commit 消息并进行提交，而其他参与者未收到 commit 消息则无法提交，于是整个事务中就会出现数据不一致的现象。
二阶段无法解决的问题。协调者再发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

其在工程中很少使用，但其有一
定的参考性；

2. 三阶段提交协议

===========

基于两阶段的问题，提出了三阶段提交协议，主要的改动点：

引入了超时机制，同时在协调者和参与者都引入超时机制
在第一阶段和第二阶段中插入准备阶段。保证了在最后提交阶段之前各参与者的状态是一致的。

三阶段提交提交协议，分为三个阶段，CanCommit 阶段、PreCommit 阶段、DoCommit 阶段。

简单理解即可，在日常的开发中，很少使用；我们重点了解 TCC 协议

3. TCC 事务协议

============

TCC 是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿(回滚)操作。它分为三个阶段：

Try 阶段：主要是对业务系统做检测及资源预留
Confirm 阶段：主要是对业务系统做确认提交，Try 阶段执行成功并开始执行 Confirm 阶段时，默认 Confirm 阶段是不会出错的。即 Try 成功，Confirm 一定会成功
Cancel 阶段：主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
当其中一个子业务系统返回失败，或者超时，则这次事务以失败处理，进入不到第二阶段。那么需要向所有子业务系统发送回滚请求，使其子业务系统释放其资源。当发送回滚请求超时时，则重复发送，以确保子业务系统回滚成功。在扣减库存而言，则解冻该库存数量。

补充：

为了避免重复发送消息，所有的子业务系统都必须提供接口幂等性原则。
为了避免主业务系统宕机，无法知晓这次事务的执行情况，需提供一个机制，记录这次事务的执行状态，待服务器重新提供服务或者定时任务定时处理事务后续的动作，以确保事务的完整性。

问题：

===

当提交超时时，该怎么处理？

需业务场景需要，是否需要回滚，还是依然继续提交。

当只要有一个子业务系统返回失败或者超时，跳到 Cancel 阶段进行回滚后直接结束这次事务。如果回滚超时或者失败该如何处理？或者中途宕机，又该如何处理？

在业务系统中需要记录该事务的执行状态以及子事务的执行状态；当发现超时或者宕机时，可以从中回复执行；

改善点：

====

在 Confirm 阶段、Cancel 阶段是否需要异步执行，可以有效的提供响应速度。

4. 最大努力通知

==========

通过异步的形式，或者采用第三方组件将请求确保将消息发送给子业务系统。其需要评估该请求在子业务必须执行成功的；否则子业务系统执行失败，主业务系统还需要进行回滚，逻辑将会变得复杂；什么情况下，会采用该机制呢？主要是发短信等必须执行成功的场景下，才会采用该方法；

4.1 本地消息表

=========

将请求保存到本地数据库，交由后台程序异步将请求推送给子业务系统。一般来讲，设计重试 3 次即可，当连续发送三次失败，即通知运维人员进行跟进处理，具体什么原因导致；如果涉及不限次数的发送，那么就会导致业务系统压力过大；

4.2 半消息/最终一致性

=============

采用 MQ，redis 等中间件，事务性的将请求推送子业务系统；前提下，需要确保该中间件是否支持事务性操作，如不支持，需业务系统评估如何才能达到事务性推送。例如 RocketMQ 消息中间，是支持事务性操作，其原理是将消息保存到临时队列，当业务系统 commit 操作时，才将该消息从临时队列移出到目标队列。

五. 副本一致性

========

5.1 raft

========

该算法中有三种角色，follower(跟随着)、candidate(候选者)、Leader(领导者)

其主要有两个环节，第一个环节是选举 Leader；第二环节是副本拷贝。

当集群中，没有 Leader 时或者 Leader 宕机时，有资格的 follower 就会变为 candidate，接着会竞聘 Leader。谁先发起竞聘，谁就有限当 Leader。至于谁先发送，其给每个 candidate 设置一个随机时间，当时间一到还没收到其他 candidate 竞聘请求的，则其会向各个 candidate 发送竞聘请求；超过半数，自动变为 Leader。

当客户端发送请求过来时，有 Leader 接收处理，并广播给其他 follower；当收到半数的回复成功时，即可确认该请求处理成功。

5.2 paxos

=========

5.2.1 目标

========

多节点之间对提案达成共识，意味着大多数节点都接受该提案。

5.2.2 角色

========

Proposer:：提议者，专门用来发出提案（一个值）；当超过半数，就认为该提案被选定的。

Acceptor：接收者，专门用来接收提案，并判断是否通过该提案；

Learner：学习者，用来学习被选定的提案（个人理解，可有可无）。

5.2.3 basic-paxos

=================

5.2.3.1 流程

==========

其简单的流程图如下，这里不考虑异常，竞争下的场景；

分布式事务与分布式系统

在 prepare 阶段，Proposer 向 Acceptor 咨询自己是否有提议权(或者发表权)。一旦超过半数 Acceptor 回复 OK，则进入 accept 第二阶段。Proposer 发发送 accept 请求，超过 Acceptor 半数回复 OK。则结束这次提议。至于 Learner 通过谁去学习这个【proposal-value】,

Acceptor 接收 prepare 请求的逻辑

如果 Acceptor 没有批准过提议权的，则无保留意见批准，并记录该 minProposal =【proposal-id】。

如果 Acceptor 之前已经批准过提议权 minProposal ，会与现在收到的提议权携带的【proposal-id】进行比较。 minProposal >=proposal-id，则拒绝该提议权；如果 minProposal <proposal-id，则批准该提议权，并记录该 minProposal =【proposal-id】。并将 Acceptor 自身的【proposal-value】以及【 minProposal 】发给 Proposer。这里留下一个提问， Acceptor 会返回不同的【 proposal-value 】麽？

Proposer 处理 prepare 请求的响应的逻辑

prepare 响应中如果有【proposal-value】A，则设置 Proposer 的【proposal-value】为 A，否则自行做决定该值。

如果超过半数回复同意的，则进入第二阶段去发表意见。

否则重新发起提议，发送 prepare 消息获取提议权。

Proposer 发送 accept 请求的逻辑

将【proposal-id】与【proposal-value】发送给 Acceptor。

Acceptor 接收 accept 请求的逻辑

如果 Acceptor 当前的【proposal-ID】A 与这次 accept 请求中的【提议 ID】B 相比较，如果不相等，则回复【NO】。否则设置 Acceptor 的【proposal-value】的值为 accept 请求中的【proposal-value】，并回复【OK】响应。

Proposer 接收 accept 请求的响应的处理逻辑

如果超过半数回复 OK 的，则不用管理其他回复【NO】响应，把该【proposal-value】发送给 Learner 进行学习。否则重新发送 prepare 消息，再进行一次提议；最终【proposal-value】是一致的。

5.2.3.2 深入探讨

============

Acceptor 是否会存在多个不同的【proposal-value】？

答案：是不会存在多个不同【proposal-value】。因为在 prepare 阶段，如果 Acceptor 已经有【proposal-value】值，Proposal 会拿这个值在 accept 阶段进行发送；如果没有的话，Proposal 会自行生成一个【proposal-value】值到 accept 阶段进行发送；同时在 accpet 阶段，如果 Acceptor 会去校验【proposal-id】是否相同，相同则设置该【proposal-value】值。有点类似乐观锁的机制。

如果 Acceptor 小部分宕机，或者 Proposal 在提议过程中发生了宕机，会不会出现【proposal-value】不一致？

答案：不会。因为该协议是只要超过半数的 Acceptor 在运转，依然可以提供服务。而 Proposal 宕机，Proposal 重启进行下一轮提议或者交由其他 Proposer 提议，最终【proposal-value】是达成一致。

并发性问题，性能低效，以及容易出现活锁问题

在多个 Proposal 进行提议时，容易对【proposal-id】进行竞争，导致性能低效，极端情况下，出现活锁现象。以及为了达成共识，需要先 prepare 阶段以及 accept 阶段，会有损耗，也是导致性能低效的原因之一。

5.2.4 multi-paxos

=================

这个就是基于 basic-paxos 中暴露的问题，提供出来的解决方案。

添加一个 leader 角色，所有的提议都由 Leader 角色来发起，这样子有效的避免竞争带来的性能低效以及活锁现象。但是从而导致 Leader 角色的服务压力过大。
有效的减少 Prepare 阶段，在满足特定的场景，Leader 可以直接跳过 prepare 阶段，直接到 accept 阶段，减少交互次数，可以有效的减少性能低效问题。

问题，

什么场景下，可以直接跳过 prepare 阶段？

只有当 Acceptor 自身发现只接收到一个 Leader 的请求时，就会告知 Leader，让其跳过 prepare 阶段；

Leader 是如何选举出来的？

兰伯特博士提出比较简单的方式，就是哪个 server 的 ID 最大，谁就是最大。也可以采用 Raft 机制，谁先发起竞聘，谁就是 Leader。

出现网络分区，该怎么处理？

兰伯特博士提出一个并发数参数来短时间避免网络分区问题，当网络分区现象发生时，超过多少笔请求接收完后，网络分区才真正会出现；例如，有 9 个节点，当网络分区发生时，6 个节点互通，而另外 3 个节点互通。当请求过来时，切好落在 3 节点区域，这时该请求是无法通过的，因为当前节点数是 9，需要过半数才能通过；当请求数超过指定的并发数时，该 3 个节点才真正的形成集群，只要超过 2 个节点的通过，即可接收该请求。