reference:

• Seata 官方文档
• TCC 理论及设计实现指南介绍
• TCC 适用模型与适用场景分析
• Seata 极简入门
• 分布式事务 Seata 及其三种模式详解
• 深度剖析 Seata TCC 模式

1 分布式事务初探

1.1 分布式事务产生背景

• 数据库的水平拆分：随着业务数据规模越来越大，单库单表逐渐成为瓶颈。对数据库水平拆分，将原单库单表拆分成数据库分片。而分库分表之后，原来在一个数据库上就能完成的写操作，可能会跨多个数据库，这就产生了跨数据库事务问题
• 业务服务化拆分：随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。而业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题

1.2 什么是 2PC

• 2PC（Two-phase Commit，二阶段提交）是为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的算法
• 事务管理器分两个阶段来协调资源管理器，第一阶段准备资源，也就是预留事务所需的资源，如果每个资源管理器都资源预留成功，则进行第二阶段资源提交，否则协调资源管理器回滚资源

1.3 什么是 TCC

• TCC （Try-Confirm-Cancel）是服务化的两阶段提交协议，具体含义如下：

  1. Try检测预留资源：尝试执行，完成所有业务检查（一致性）， 预留必须业务资源（准隔离性）
  2. Confirm执行真正的业务操作提交：如果所有分支的 Try 都成功了，则走到 Confirm 阶段。不作任何业务检查，只使用 Try 阶段预留的业务资源
  3. Cancel释放预留资源：如果有一个分支 Try 失败，则走到 Cancel 阶段，释放预留的资源

  

• 业务开发者需要实现这三个服务接口，第一阶段服务由业务代码编排来调用 Try 接口进行资源预留，所有参与者的 Try 接口都成功了，事务管理器会提交事务，并调用每个参与者的 Confirm 接口真正提交业务操作，否则调用每个参与者的 Cancel 接口回滚事务

• 用户实现 TCC 服务之后，该 TCC 服务将作为分布式事务的其中一个资源，参与到整个分布式事务中

1.4 TCC 模型的优势

• TCC 分布式事务模型直接作用于服务层。不与具体的服务框架耦合，与底层 RPC 协议无关，与底层存储介质无关，可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好
• 在按照功能横向扩展资源时（服务的拆分），TCC 可以保证多资源访问的事务属性
• 另一个作用是拆分成了两个独立的阶段，通过资源业务锁定的方式进行关联，允许第二阶段的异步执行。这样既不会阻塞其他事务在一阶段对于相同资源的继续使用，也不会影响本事务二阶段的正确执行

1.5 AT 与 TCC 适用场景对比

• AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，学习成本低
• TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景