TCC分布式事务的设计、实现与示例

- 微信原文：点击 [TCC分布式事务的设计、实现与示例](https://mp.weixin.qq.com/s/0Jd-H7fvq2_EfhfP196uHg) - 可以关注我微信公众号，有很多优质文章 【技术闲聊吧】，或点开上面文章，关注作者即可 - 大家赏个star吧 ： https://github.com/ikenchina/octopus # 理论 ## 论文 Pat Helland于2007年发表tcc论文《Life beyond Distributed Transactions: an Apostate’s Opinion》，提出了TCC的概念，在论文中，TCC还是以Tentative-Confirmation-Cancellation命名的，后来Atomikos公司改名为Try-Confirm-Cancel。 TCC事务相对于传统事务（XA， Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的接口调用来实现分布式事务。 ## 理论 TCC事务有一系列子事务构成，每个子事务所属的RM需要提供Try-Confirm-Cancel三个接口来给事务协调者调用。 TCC和2PC类似，也是分为两个阶段，Try阶段和Confirm或Cancel阶段。 - 第一阶段Try：进行资源检查与预留。尝试执行，完成所有业务一致性检查，预留业务资源，但不会对资源进行锁定。 - 第二阶段 - Confirm：确认，真正执行业务，处理Try 阶段预留的业务资源，Confirm 操作要求具备幂等设计，只要进入到Confirm阶段，则事务就已经处于提交状态了，所以Confirm 失败后需要进行重试直到成功为止。 - Cancel：取消，释放 Try 阶段预留的业务资源。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致，要求满足幂等设计。 > TCC不会对在数据资源层面对资源进行锁定，但是会进行业务层面的预留，以将资源层的加锁升级到业务层上，这样业务层可以灵活实现隔离性，达到准隔离性的同时提高并发性能。 ## 举例 仍然使用转账的例子：A和B账户余额都是100元，A转账30元给B。 这个TCC事务有两个子事务， - 子事务A：从A的账户减去30元，提交后A的账户余额为70元 - 子事务B：给B的账户添加30元，提交后B的账户余额为130元 需要在资源层将增加一个资源字段冻结余额 **执行事务**： - 第一阶段，Try： - 检查A的余额是否大于等于30元，利用资源层事务的原子性，在A的冻结余额中增加-30元，不修改A的余额 ，所以A的账户余额还是100元。其他事务看到的余额总数还是100元。 - 将B的冻结余额增加+30元，不修改B的账户余额，其他事务看到的B的账户余额仍然是100元。 - 第二阶段， - Confirm： - 将A的账户的冻结余额的-30元加到账户余额中，那么A的账户余额等于70元。 - 将B的账户的冻结余额的+30元加到账户余额中，B的账户余额等于130元。 - Cancel： - 将A的账户的冻结余额清空 - 将B的账户的冻结余额清空 **隔离性：** 事务执行期间，A和B的账户余额还是100元，但是如果其他事务需要并发修改A或B的账户余额，则需要考虑冻结余额。 - 如果其他事务需要修改A的账户余额，则需要查看冻结余额，发现已经冻结了-30元，则只有70元是可用的 - 如果其他事务需要修改B的账户余额，则需要查看冻结余额，发现已经冻结了+30元，则只有100元是可用的 或者事务执行期间，不允许其他事务修改A和B的的账户余额。 > 所以，将锁从资源层上升到业务层，隔离性更加灵活，需要如何实现隔离性，完全由业务决定，也避免了资源层并发带来的回滚。 ## 使用场景 - 适用于业务流程短的事务 - 隔离性较好：对中间状态有约束的业务 ### 优点 - 并发度较高，不需要像XA事务对资源进行锁定 - 隔离性比Saga好，取决于业务实现 ### 缺点 - 对业务有侵入性：需要实现Try，Confirm，Cancel接口 - 参与者需要实现幂等 # 设计 ## 基础概念 TCC事务由三种角色组成 - TCC事务提交者：事务发起者，在分布式事务中统称为AP - TCC事务协调者：接受AP的事务请求，管理TCC事务，在分布式事务中统称为事务协调者(TC : Transaction Coordinator) - TCC子事务参与者：协调者将子事务提交给参与者执行， 在分布式事务中统称为资源管理器(RM：Resource Manager)。参与者需要包证接口的幂等性 **事务状态** - committed : 已经提交。最终态 - aborted ：已经回滚。最终态 - failed ：回滚中或提交失败(可能重试中)。非终态 - prepared：提交中。非终态 ## TCC事务协调者的实现 TCC Service - 提供RESTful API，AP通过API进行事务提交或查询 - TCC service将请求封装成TCC事务对象，提交给TCC Executor执行 - API结果响应： - 如果是同步请求，则等待TCC Executor处理完成，再将结果封装成TccResponse 给AP - 如果是异步请求，则马上返回给AP - 通知：TC通知 AP TCC事务执行的结果 TCC Executor - TCC事务真正的执行者，管理TCC事务的状态转换，重试，持久化等等，不涉及与RM和AP的交互 - TCC子事务处理和回滚：TCC Executor并不处理子事务，而是将子事务操作写入Channel，由外层去向RM发送子事务请求 - TCC事务通知：TCC Executor不执行具体的通知操作，而是将操作写入Channel，由外层去执行AP - 数据持久化：TCC Executor将TCC数据存储到本地数据库中来保证数据的持久化，也同时依赖本地数据库的事务特性。 ## 事务流程 - 开启TCC事务：AP调用 TC的prepare接口，开启一个TCC事务 - 循环处理所有子事务：如果某个步骤失败，重试策略取决于AP - 注册子事务（分支事务）：AP调用TC register接口，注册一个子事务，注册成功再执行下一步 - Try：AP调用RM的Try接口 - Confirm：如果所有子事务都成功注册和执行try，则AP调用TC的Confirm接口，告知事务可以执行提交 - TC循环调用所有参与子事务的RM的Confirm接口，如果返回失败则会一直重试指导成功 - Cancel：如果子事务执行失败，AP不进行重试则调用TC的Cancel接口取消TCC事务；或者达到TCC事务过期时间，TC会自行取消TCC事务。 - 循环调用所有子事务的RM，调用RM的Cancel接口 ## 异常情况处理 分布式事务实现的一个难点就是时序问题，主要体现在： - 服务器的时钟不同步 - 请求乱序 因此会产生一些不可预测的异常。 ### TCC事务过期 如果TCC事务过期，则TC需要先将事务的状态标记为"需要Cancel"状态，再调用RM的Cancel接口来取消子事务。 如果后续TC接受到此TCC事务的Confirm请求，TC应先查看本地数据库中此事务状态，如果已经处于Cancel或者已经Cancel，则应该拒绝Confirm请求。 同时，TC对数据库中事务的状态修改，应该使用数据库事务来确保隔离性和一致性，因为可能有多个TC同时存在。 ### 回滚异常 异常流程如下： - TC向RM发送Try请求 - 由于网络原因Try请求仍然处于发送中，没有到达RM - AP调用TC取消TCC事务，或者TCC事务过期，TC自行取消 - TC调用RM的Cancel接口取消子事务 - 异常点1 ：RM收到Cancel请求，发现此子事务没有执行过Try，产生异常 - 异常点2 ：当RM收到Cancel请求后，之前由于网络原因阻塞的Try请求到达RM，如果RM执行这个Try，则会产生数据不一致的异常。 - 异常点3：由于重试策略，导致AP向RM发送了多于1次的Try请求，或者TC向RM发送了多次Confirm或者Cancel请求。 所以，为了避免上面异常情况，需要进行如下检查 - RM收到Try操作， 检查是否有Try记录 - 如果有记录：如果已经执行过Try，直接返回成功，确保幂等性 - 如果没有Try记录，则检查是否有Cancel记录， - 如果有Cancel记录，则拒绝执行Try - 如果没有Cancel记录，则执行Try，且更改子事务状态为"已经执行try"。 - RM收到Cancel操作，查看此子事务是否有Cancel记录， - 如果有Cancel记录，则直接返回Cancel成功，确保幂等性 - 如果没有Cancel记录，则检查是否有Try记录 - 如果有Try记录，则执行Cancel动作 - 如果没有Try记录，则将此Cancel请求记录下来，如果后续收到Try请求，则应该拒绝Try请求 ### 本地事务 无论是RM还是TC或AP，在修改其数据时要考虑时序问题和时钟漂移问题导致的乱序，利用本地数据库的事务隔离(可序列化级别)特性来检查事务状态和修改状态。 如： RM收到Try请求后，需要检查是否有Cancel记录或Try记录，没有才能需要执行Try。检查和执行需要在一个事务中，避免其他线程或进程同时对子事务进行Cancel或者Try修改。 # 开发示例 以银行转账为示例，演示如果通过SDK来实现一个tcc事务。 此演示使用了SDK的高级API，屏蔽了各种异常情况的处理，提高了开发的效率。 **开发示例** https://github.com/ikenchina/octopus/blob/master/README_tcc_demo.md **SDK** client sdk实现了AP和RM的sdk封装，方便进行tcc开发。 client SDK：https://github.com/ikenchina/octopus/blob/master/README_tcc_sdk.md **API设计** https://github.com/ikenchina/octopus/octopus/README_tcc_api.md