主讲 王启军 华为云PasaS团队架构师

问题引出

在单体架构下为了保证一致性可以使用事务，而在分布式架构下是无法使用单库事务来实现一致性的。两阶段提交依赖于数据库并且存在问题

举例：经典场景，A账号转账至B账号，当A账号转出成功了、B账号转入失败了，这时如何向用户返回呢？

2PC的解决方式

2PC的两种场景

2PC（两阶段提交）解决此问题的正常场景如下：

1. 第一阶段：协调者发起请求询问两个参与者1、2，是否可以提交，接下来参与者1锁定数据返回可以提交、参与者2锁定数据返回可以提交
2. 第二阶段：协调者发起请求命令两个参与者1、2提交，参与者1返回提交成功了，参与者2也返回提交成功了，正常提交流程结束

异常场景：

在第一阶段，协调者发起请求询问是否可以提交，参与者1锁定数据返回可以提交，参与者2返回不可提交，那么第二阶段协调者发起取消提交的命令，参与者1、2取消提交

2PC的问题

参与者1一定是要加锁的，容易出现死锁情况，例如当协调者挂了，参与者1加锁后不知道另一个参与者的存在。如果用超时回退的方法避免死锁，则会产生不一致的情况出现。

这里的锁是悲观锁，性能比较差，参与者数量增加会导致性能指数下降

TCC的解决方式

try-confirm-cancel：Pat Helland在07年发表的论文中提出

相比于2PC，TCC的特点：

• 优点：不依赖数据库协议，也就是数据不用锁，事务过程由业务服务实现，不会出现死锁问题，降低了数据库的压力
• 缺点：导致业务变得复杂，数据库需要增加字段表示状态，需要增加接口实现confirm、cancel的方法，业务要自己保证每个方法的幂等（因为可能涉及到失败重试的问题）

在业务中实现TCC机制

• 主业务发起事务，并调用从业务try接口，检测业务数据一致性，预留数据资源
• try返回成功，分别调用从业务confirm接口，提交数据资源（这是无需检测数据有效性，已经在上一步预留了）
• try执行时，任何从业务失败或超时，都会分别调用cancel接口，释放预留资源

代码实现时，业界一般会将TCC协调器抽象成一个库，内嵌到业务服务中，也就是说业务服务进程是同一个进程，但协调器挂掉怎么办呢，如果通过部署多个业务服务貌似可以解决，但服务间并不共享状态数据。

那么，这里引出一种方案：将业务协调器独立成一个业务服务，这样业务服务和协调器互不影响，协调器可以部署多个，数据存在DB里

待解决问题

失败后 重试好还是回滚好，通常把这个选择交给业务方处理