分布式事务之TCC服务设计和实现注意事项 二阶段 三阶段 PC

 

分布式事务：分布式事务原理概述-阿里云开发者社区 https://developer.aliyun.com/article/608863

1、什么是分布式事务

分布式事务就是指事务的资源分别位于不同的分布式系统的不同节点之上的事务；

2、分布式事务产生的原因

2.1、数据库分库分表

在单库单表场景下，当业务数据量达到单库单表的极限时，就需要考虑分库分表，将之前的单库单表拆分成多库多表；

分库分表之后，原来在单个数据库上的事务操作，可能就变成跨多个数据库的操作，此时就需要使用分布式事务；

2.2、业务服务化

业务服务化即业务按照面向服务（SOA）的架构拆分整个网站系统；

比如互联网金融网站SOA拆分，分离出交易系统、账务系统、清算系统等，交易系统负责交易管理和记录交易明细，账务系统负责维护用户余额，所有的业务操作都以服务的方式对外发布；

一笔金融交易操作需要同时记录交易明细和完成用户余额的转账，此时需要分别调用交易系统的交易明细服务和账务系统的用户余额服务，这种跨应用、跨服务的操作需要使用分布式事务才能保证金融数据的一致性；

3、分布式事务原理简介

3.1、ACID

1、原子性（Atomicity）

整个事务中的所有操作，要么都成功，要么都失败，不可能部分操作成功部分操作失败；

2、一致性（Consistency）

事务必须使数据库的数据从一个一致性状态变换到另外一个一致性状态。

3、隔离性（Isolation）

事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

4、持久性（Durability）

在事务成功以后，该事务对数据库所做的更改应当持久的保存在数据库中；

3.2、2PC

两阶段提交协议（Two Phase Commitment Protocol）是分布式事务的基础协议。

在此协议中，一个事务协调器（TM, transaction manager）协调多个资源管理器（RM, resource manager）的活动；在一阶段所有资源管理器（RM）向事务管理器（TM）汇报自身活动状态，在第二阶段事务管理器（TM）根据各资源管理器（RM）汇报的状态，来决定各RM是执行提交操作还是回滚操作；具体描述如下：

1) 应用程序向事务管理器（TM）提交请求，发起方分布式事务；

2) 一阶段，事务管理器（TM）联络所有资源管理器（RM），通知它们执行准备操作；

3) 资源管理器（RM）返回准备成功，或者失败的消息给TM（响应超时算作失败）；

4) 二阶段，如果所有RM均准备成功，TM会通知所有RM执行提交；如果任一RM准备失败，TM会通知所有RM回滚；

通过事务管理器2阶段协调资源管理器，使所有资源管理器的状态最终都是一致的，要么全部提交，要么全部回滚。

3.3、2PC应用之XA

XA是X/Open组织提出的，定义了事务管理器与资源管理器之间通信的接口协议；XA协议由数据库实现，目前支持XA协议的数据库有Oracle、MySql、BD2等；

XA定义了一系列的接口：

• xa_start: 启动XA事务
• xa_end: 结束XA事务
• xa_prepare: 准备阶段，XA事务预提交
• xa_commit： 提交XA事务
• xa_rollback: 回滚XA事务

一个数据库实现XA协议之后，它就可以作为作为一个资源管理器参与到分布式事务中;

在一阶段，事务管理器协调所有数据库执行XA事务（xa_start、用户SQL、xa_end），并完成XA事务预提交（xa_prepare）；

在二阶段，如果所有数据库上XA事务预提交均成功，那么事务管理器协调所有数据库提交XA事务（xa_commit）；如果任一数据库上XA是我预提交失败，那么事务管理器会协调所有数据组回滚XA事务（xa_rollback）;

3.4、2PC应用之TCC

TCC是Try、Confirm、Cancel 3个操作的缩写；

Try操作对应2PC的一阶段Prepare，Confirm对应2PC的二阶段commit，Cancel对应2PC的二阶段rollback；

这3个操作均有用户编码实现；

TCC三个操作描述：

• Try: 检测、预留资源;
• Confirm: 业务系统执行提交；默认Confirm阶段是不会出错的，只要TRY成功，CONFIRM一定成功；
• Cancel: 业务取消，预留资源释放;

用户通编码实现TCC并发布成服务，这个TCC服务就可以作为资源参与到分布式事务中；事务管理器分2阶段协调所有的TCC资源，使得所有TCC资源状态最终都是一致，要么全部提交，要么全部回滚；

TCC自编码的特性决定TCC资源管理器可以跨DB、跨应用实现资源管理，将对不同的DB访问、不同的业务操作通过编码方式转换一个原子操作，解决了复杂业务场景下的事务问题；

同时TCC的每一个操作对于DB来讲都是一个本地DB事务，操作结束则本地DB事务结束，数据库的资源也就被释放；这就规避了数据库层面的2PC对资源占用导致的性能低下问题；

3.5、柔性事务

单数据库事务完全遵循ACID规范，属于刚性事务，分布式事务要完全遵循ACID规范比较困难, 分布式事务属于柔性事务，满足BASE理论；

BASE描述： BA（Basic Availability 基本业务可用性）、S（Soft state 柔性状态）、E（Eventual consistency 最终一致性）；

柔性事务对ACID的支持：

1、原子性：

严格遵循；

2、一致性：

事务完成后的一致性严格遵循，事务中的一致性可适当放宽；

3、隔离性：

并行事务间不可影响；事务中间结果可见性允许安全放宽；

4、持久性：

严格遵循；

为了可用性、性能的需要，柔性事务降低了一致性(C)与隔离性(I) 的要求，即“基本可用，最终一致”；

3.6、柔性事务的分类

柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型；

1、两阶段型

就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS，这是分布式环境下事务处理的典型模式。

2、补偿型

TCC型事务（Try/Confirm/Cancel）可以归为补偿型；TCC思路是:尽早释放锁；在Try成功的情况下，如果事务要回滚，Cancel将作为一个补偿机制，回滚Try操作；

TCC各操作事务本地化，且尽早提交 (放弃两阶段约束)；当全局事务要求回滚时，通过另一个本地事务实现“补偿”行为；

TCC是将资源层的两阶段提交协议转换到业务层，成为业务模型中的一部分；

3、异步确保型

将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用；比如消息事务机制；

4、最大努力通知型

通过通知服务器(消息通知)进行，允许失败，有补充机制；

 

 

 

分布式事务之TCC服务设计和实现注意事项-云栖社区-阿里云 https://yq.aliyun.com/articles/609854

 

1、TCC简介

TCC是一种比较成熟的分布式事务解决方案，可用于解决跨库操作的数据一致性问题；

TCC是服务化的两阶段编程模型，其Try、Confirm、Cancel 3个方法均由业务编码实现；

其中Try操作作为一阶段，负责资源的检查和预留，Confirm操作作为二阶段提交操作，执行真正的业务，Cancel是预留资源的取消；

如下图所示，业务实现TCC服务之后，该TCC服务将作为分布式事务的其中一个资源，参与到整个分布式事务中；事务管理器分2阶段协调TCC服务，在第一阶段调用所有TCC服务的Try方法，在第二阶段执行所有TCC服务的Confirm或者Cancel方法；

2、用户在实现TCC服务时，有以下注意事项

• 1、业务操作分两阶段完成：

如下图所示，接入TCC前，业务操作只需要一步就能完成，但是在接入TCC之后，需要考虑如何将其分成2阶段完成，把资源的检查和预留放在一阶段的Try操作中进行，把真正的业务操作的执行放在二阶段的Confirm操作中进行；

TCC服务要保证第一阶段Try操作成功之后，二阶段Confirm操作一定能成功；

• 2、允许空回滚；

如下图所示，事务协调器在调用TCC服务的一阶段Try操作时，可能会出现因为丢包而导致的网络超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操作；

TCC服务在未收到Try请求的情况下收到Cancel请求，这种场景被称为空回滚；TCC服务在实现时应当允许空回滚的执行；

• 3、防悬挂控制；

如下图所示，事务协调器在调用TCC服务的一阶段Try操作时，可能会出现因网络拥堵而导致的超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操作；在此之后，拥堵在网络上的一阶段Try数据包被TCC服务收到，出现了二阶段Cancel请求比一阶段Try请求先执行的情况；

用户在实现TCC服务时，应当允许空回滚，但是要拒绝执行空回滚之后到来的一阶段Try请求；

• 4、幂等控制：

无论是网络数据包重传，还是异常事务的补偿执行，都会导致TCC服务的Try、Confirm或者Cancel操作被重复执行；用户在实现TCC服务时，需要考虑幂等控制，即Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的；

• 5、业务数据可见性控制；

TCC服务的一阶段Try操作会做资源的预留，在二阶段操作执行之前，如果其他事务需要读取被预留的资源数据，那么处于中间状态的业务数据该如何向用户展示，需要业务在实现时考虑清楚；通常的设计原则是“宁可不展示、少展示，也不多展示、错展示”；

• 6、业务数据并发访问控制；

TCC服务的一阶段Try操作预留资源之后，在二阶段操作执行之前，预留的资源都不会被释放；如果此时其他分布式事务修改这些业务资源，会出现分布式事务的并发问题；

用户在实现TCC服务时，需要考虑业务数据的并发控制，尽量将逻辑锁粒度降到最低，以最大限度的提高分布式事务的并发性；

3、总结

蚂蚁金服使用TCC有10年历史，在TCC应用方面积累了大量实践经验；除了上述TCC服务的设计注意事项外，我们在解决用户高并发、高可用需求方面也提供了解决方案，我们对分布式事务做了极致的性能优化以支持双11等大促的高并发需求，我们基于蚂蚁LDC架构的高可用方案能使分布式事务服务达到99.99%的可用性；

蚂蚁金服大部分业务系统均采用TCC的方式接入分布式事务，但设计TCC服务时要遵循大量设计规范，这无疑对用户提了非常高的要求；为了简化用户接入分布式事务的门槛，蚂蚁金服的分布式事务框架（SOFA-DTX）推出了FMT（Framework-managed transactions）模式和XA模式，这两种模式均不需要用户实现TCC服务，用户只需要关注自身业务SQL便可；DTX的三种模式：TCC、FMT和XA相互之间是功能互补，相辅相成的，形成了蚂蚁金服完善的分布式事务解决方案。

SOFA-DTX全面覆盖金融场景，金融级容灾保障、提供丰富的接入模式并且使用简洁易于接入；目前已经应用在支付宝、网上银行、蚂蚁财富、芝麻信用、南京银行等项目中。

 

翻译

搜索

复制