分布式事务解决方案——柔性事务TCC（Base原则）

柔性事务

所谓柔性事务，相比较与数据库事务中的ACID这种刚性事务来说，柔性事务保证的是“基本可用，最终一致。”这其实就是基于BASE理论，保证数据的最终一致性。

虽然柔性事务并不像刚性事务那样完全遵循ACID，但是，也是部分遵循ACID的，简单看一下关于ACID四个属性，柔性事务的支撑程度：

原子性：严格遵循

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

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

持久性：严格遵循

关于柔性事务，最主要的有以下四种类型：两阶段型、异步确保型、补偿型、最大努力通知型。

 

 

 

柔性事务的模式：幂等操作、可补偿操作、可查询操作和TCC操作

1、可查询操作：为了保证操作的可查询，需要对于每一个服务的每一次调用都有一个全局唯一的标识，可以是业务单据号（如订单号）、也可以是系统分配的操作流水号（如支付记录流水号）。除此之外，操作的时间信息也要有完整的记录。

 

2、幂等操作：幂等性，其实是一个数学概念。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。也就是说，同一个方法，使用同样的参数，调用多次产生的业务结果与调用一次产生的业务结果相同。

幂等操作的实现方式有多种，如在系统中缓存所有的请求与处理结果、检测到重复操作后，直接返回上一次的处理结果等。

 

3、可补偿操作：比如，在调用积分服务给积分帐户增加积分操作执行之后，操作执行之后，经过分布式事务协调，最终决定回滚整个事务，那么就需要提供一个调用积分服务给积分帐户扣减积分的操作。

 

4、TCC操作：Try-Confirm-Cancel

Try: 尝试执行业务

完成所有业务检查(一致性) 预留必须业务资源(准隔离性)

Confirm:确认执行业务

真正执行业务 不作任何业务检查 只使用Try阶段预留的业务资源 Confirm操作要满足幂等性

Cancel: 取消执行业务

释放Try阶段预留的业务资源  
Cancel操作要满足幂等性

这种类型和可补偿操作类似，就是提供一种提交和回滚的机制。是一种典型的两阶段类型的操作。这里说的两阶段类型操作并不是指2PC，他和2PC还是有区别的。

 

TCC与2PC协议比较

TCC位于业务服务层而非资源层

TCC没有单独的准备(Prepare)阶段,Try操作兼备资源操作与准备能力

Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度)

TCC有较高开发成本

所谓的TCC编程模式，也是两阶段提交的一个变种。TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

 

TCC事务=是为了解决应用拆分带来的跨应用业务操作原子性的问题

• Try：预留业务资源：把多个应用中的业务资源预留和锁定住，为后续的确认打下基础
• Confirm：确认执行业务操作：在Try操作中涉及的所有应用均成功之后进行确认，使用预留的业务资源
• Cancel：取消执行业务操作：当Try操作中涉及的所有应用没有全部成功，需要将已成功的应用进行取消(即Rollback回滚)

 

 

一个案例理解TCC

账务拆分的业务场景如下，分别位于三个不同分库的帐户ABC，A和B一起向C转帐共80元。

1、Try：尝试执行业务。

• 完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。
• 预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。

2、Confirm：确认执行业务。

• 真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。
• 不做任何业务检查：这时已经不需要做业务检查，Try阶段已经完成了业务检查。
• 只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。

3、Cancel：取消执行业务

• 释放Try阶段预留的业务资源：如果Try阶段只有部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。

 

参考链接：

http://www.hollischuang.com/archives/2591

https://mp.weixin.qq.com/s/9jHAUtiG-ZBI6eKUEiEmYw