简介：讲解TCC柔性事务的解决方案
- 什么是TCC柔性事务
- 刚性事务：遵循ACID
- 柔性事务：遵循BASE理论
- TCC:
- 将事务提交分为
- Try：完成所有业务检查( 一致性 ) ，预留必须业务资源( 准隔离性 )
- Confirm ：对业务系统做确认提交，默认 Confirm阶段不会出错的 即只要Try成功，Confirm一定成功
- Cancel : 业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放, 进行补偿性
- TCC 事务和 2PC 的类似，Try为第一阶段，Confirm - Cancel为第二阶段，它对事务的提交/回滚是通过执行一段 confirm/cancel 业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑
- 将事务提交分为
| 含义 | 操作方法 |
|---|---|
| 预留业务资源/数据效验 | Try |
| 确认执行业务操作，提交数据，不做任何业务检查，try成功，confirm必定成功，需保证幂等 | Confirm |
| 取消执行业务操作，回滚数据，需保证幂等，也是常说的补偿性事务 | Cancel |
- 看下TCC的交互图（图片来源网上）
-
- 优点：
- 它把事务运行过程分成 Try、Confirm/Cancel 两个阶段
- 每个阶段由业务代码控制，这样事务的锁力度可以完全自由控制
- 不存在资源阻塞的问题，每个方法都直接进行事务的提交
- 缺点
- 在业务层编写代码实现的两阶段提交，原本一个方法，现在却需要三个方法来支持
- 对业务的侵入性很强，不能很好的复用
- 注意：使用TCC时要注意Try - Confirm - Cancel 3个操作的幂等控制，由于网络原因或者重试操作都有可能导致这几个操作的重复执行
本文作者为DBC，转载请注明。
