探求散布式事务处置打算 八种打算解析

探求散布式事务处置打算：八种打算解析

前面曾经学习了散布式事务的基础通常CAP 通常和 BASE 通常，以通常为基础，针对不同的散布式场景业界经常出现的处置打算有2PC、TCC、牢靠信息最终分歧性、最大抵力通知等打算,**以下 总结8 种经常出现的处置打算，取名八奇技**。协助大家在实践的散布式系统中更好地运用事务。。

二阶段提交协定（Two-phase commit protocol），简称 2PC。2PC是将整个事务流程分为两个阶段：

2是指两个阶段，P是指预备阶段，C是指提交阶段

在计算机中局部相关数据库如Oracle、MySQL支持两阶段提交协定，如下图：

留意:必定在最后阶段监禁锁资源

下图展现了2PC的两个阶段，分红功和失败两个状况说明：

2PC优缺陷：

好处

缺陷：

3PC，即Three-Phase Commit，是一种散布式事务协定，用于在散布式系统中确保多个介入者之间的事务操作的分歧性和牢靠性。它是在两阶段提交（2PC）协定的基础上开展而来，处置了2PC协定或许出现的悬挂事务疑问。

3PC协定将提交操作分为三个阶段，区分是预备阶段、提交预备阶段和提交阶段，每个阶段都有对应的操作和协定。

预备阶段（CanCommit）：

提交预备阶段（PreCommit）：

提交阶段（DoCommit/DoAbort）：

3PC协定相关于2PC协定的改良在于参与了一个预备阶段，使得介入者在预备阶段就能够知道能否可以提交事务，从而防止了悬挂事务疑问。但是，3PC协定依然存在着协调者单点缺点、信息失落等疑问，因此在实践运行中并不经常出现，普通更多地经常使用2PC、Saga等散布式事务处置打算

TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务虚现三个操作：预处置Try、确认Confirm、撤销Cancel。Try操作业务审核及资源预留，Confirm做业务确认操作，Cancel成功一个与Try雷同的操作即回滚操作。TM首先动员一切的分支事务的try操作，任何一个分支事务的try操作口头失败，TM将会动员一切分支事务的Cancel操作，若try操作所有成功，TM将会动员一切分支事务的Confirm操作，其中Confirm/Cancel操作若口头失败，TM会启动重试。

TCC分为三个阶段

TCC须要留意三种意外处置

空回滚

在没有调用 TCC 资源 Try 方法的状况下，调用了二阶段的 Cancel 方法，Cancel 方法须要识别出这是一个空回滚，而后间接前往成功。

出现要素：是当一个分支事务所在服务宕机或网络意外，分支事务调用记载为失败，这个时刻其实是没有口头Try阶段，当缺点复原后，散布式事务启动回滚则会调用二阶段的Cancel方法，从而构成空回滚。

处置思绪是

关键就是要识别出这个空回滚。思绪很便捷就是须要知道一阶段能否口头，假设口头了，那就是反常回滚；假设没口头，那就是空回滚。

幂等

TCC二阶段提交重试机制不会引发数据不分歧，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保障幂等，这样不会重复经常使用或许监禁资源。假设幂等控制没有做好，很有或许造成数据不分歧等重大疑问。

处置思绪在上述“分支事务记载”中参与口头形态，每次口头前都查问该形态。

悬挂

悬挂就是关于一个散布式事务，其二阶段 Cancel 接口比 Try 接口先口头。

出现要素：在 RPC 调用分支事务try时，先注册分支事务，再口头RPC调用，假设此时 RPC 调用的网络出现拥挤，通常 RPC 调用是有超时期间的，RPC 超时，TM就会通知RM回滚该散布式事务，或许回滚成功后，RPC 恳求才抵达介入者真正口头，而一个 Try 方法预留的业务资源，只要该散布式事务才干经常使用，该散布式事务第一阶段预留的业务资源就再也没有人能够处置了，关于这种状况，咱们就称为悬挂，即业务资源预留后没法继续处置。

处置思绪：假设二阶段口头成功，那一阶段就不能再继续口头。在口头一阶段事务时判别在该全局事务下，“分支事务记载”表中能否曾经有二阶段事务记载，假设有则不口头Try。

TCC优缺陷：

TCC的好处：

TCC的缺陷

4. 散布式补救事务（Saga）

Saga是一种长事务的处置打算，它将一个大的散布式事务拆分红多个较小的本地事务，并经过异步信息传递来串联这些本地事务。每个本地事务口头成功后，会发送信息触发下一个事务的口头。假设某个本地事务失败，Saga会口头一系列补救操作，坚持数据的分歧性。

散布式补救事务（Saga） 优缺陷

好处

缺陷

在选用经常使用Saga形式时，须要细心思索业务场景能否适宜最终分歧性，以及能否能够有效地成功和治理补救逻辑。关于须要高度分歧性保障的场景，或许须要思索其余事务治理机制。Saga形式在适当的状况下可以为散布式系统带来灵敏性和容错性，但须要谨慎思索其复杂性和成功难度。

5. 牢靠信息最终分歧性

牢靠信息最终分歧性打算：是指当事务动员方口头成功本地事务后并收回一条信息，事务介入方(信息消费者)必定能够接纳信息并处置事务成功，此打算强调的是只需信息发给事务介入方最终事务要到达分歧。

此打算是应用信息两边件成功，如下图：

事务动员方（信息消费方）将信息发给信息两边件，事务介入方从信息两边件接纳信息，事务动员方和信息两边件之间，事务介入方（信息消费方）和信息两边件之间都是经过网络通讯，由于网络通讯的不确定性会造成散布式事务疑问。

牢靠信息最终分歧性打算要处置以下几个疑问

1. 本地事务与信息发送的原子性疑问

本地事务与信息发送的原子性疑问即：事务动员方在本地事务口头成功后信息必定收回去，否则就摈弃信息。即成功本地事务和信息发送的原子性，要么都成功，要么都失败。本地事务与信息发送的原子性疑问是成功牢靠信息最终分歧性打算的关键疑问。 先来尝试下这种操作，先发送信息，再操作数据库：

 ； transation

这种状况下无法保障数据库操作与发送信息的分歧性，由于或许发送信息成功，数据库操作失败立马想到第二种打算，先启动数据库操作，再发送信息：

 ； transation

这种状况下貌似没有疑问，假设发送MQ信息失败，就会抛出意外，造成数据库事务回滚。但假设是超时意外，数据库回滚，但MQ其实曾经反常发送了，雷同会造成不分歧。

2. 事务介入方接纳信息的牢靠性

事务介入方必定能够从信息队列接纳到信息，假设接纳信息失败可以重复接纳信息。

3. 信息重复消费的疑问

由于网络2的存在，若某一个消费节点超时但是消费成功，此时信息两边件会重复投递此信息，就造成了信息的重复消费。要处置信息重复消费的疑问就要成功事务介入方的方法幂等性

6. 本地信息表打算

本地信息表这个打算最后是eBay提出的，此打算的外围是经过本地事务保障数据业务操作和信息的分歧性，而后经过定时义务将信息发送至信息两边件，待确认信息发送给消费方成功再将信息删除。

上方以注册送积分为例来说明： 共有两个微服务交互，用户服务和积分服务，用户服务担任参与用户，积分服务担任参与积分。

交互流程

 ； transation

这种状况下，本地数据库操作与存储积分信息日志处于同一个事务中，本地数据库操作与记载信息日志操作具有原子性。

思索:如何保障将信息发送给信息队列呢？

如何保障消费者必定能消费到信息呢？

积分服务接纳到”参与积分“信息，开局参与积分，积分参与成功后向信息两边件回应ack，否则信息两边件将重复 投递此信息。由于信息会重复投递，积分服务的”参与积分“配置须要成功幂等性

7.最大抵力通知准则

最大抵力通知也是一种基于信息的散布式事务处置打算，但它不保障 100% 的信息传递成功。它的上班原理是：

处置打算思维不同

牢靠信息分歧性，动员通知方须要保障将信息收回去，并且将信息发到接纳通知方，信息的牢靠性关键由动员通知方来保障。

两者的业务运行场景不同

技术处置方向不同

8. 散布式锁

在某些业务场景，经常使用散布式锁是确保多个散布式节点不会同时操作同一资源的有效方法。这一机制可以经过经常使用像Redis、ZooKeeper等散布式协调服务来成功

运行场景： 在电商秒杀优惠中，为了防止超卖现象，须要确保同一期间只要一个恳求能够对库存数量启动修正。这时，可以经常使用Redis作为散布式锁的后端存储，以确保秒杀优惠的启动顺利和偏心。

介绍场景： 当须要协调多个节点对共享资源启动访问控制时，散布式锁是一个十分有效的处置打算。例如，在散布式系统中，多个节点须要同时对同一资源启动读取或降级操作时，为了保障数据的分歧性和防止竞态条件，可以经常使用散布式锁来启动并发控制。