189 8069 5689
小编给大家分享一下TCC事务分段提交的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
成都创新互联专业为企业提供汤阴网站建设、汤阴做网站、汤阴网站设计、汤阴网站制作等企业网站建设、网页设计与制作、汤阴企业网站模板建站服务，10多年汤阴做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
分布式事务在业务系统中是十分常见的，最经典的场景就是电商架构中的交易业务，如图：
客户端通过请求订单服务，执行下单操作，实际上从订单服务上又触发了多个服务链请求，基本步骤如下：
客户端请求在订单服务上创建订单；
订单服务调用账户服务扣款；
订单服务调用库存服务执行库存扣减；
订单通过物流服务，转化为物流运单；
这套流程在电商系统中是基本业务，在实际的开发中远比这里描述的复杂。
上述1中是业务性的流程概念描述，从系统开发层面，在微服务的架构模式下，通常的时序流如下：
这样服务间的通信时序图在程序设计中十分常见，在分布式系统中，清楚的描述各个服务间的通信流程是十分关键的。
上图描述的交易流程是在最理想的状态下，各个服务都执行成功，但是程序是不能100%保证一直正常，经常出现如下情况：
服务间通信失败；
单个节点服务宕掉；
服务接口执行失败；
这些都是实际开发中经常出现的问题，比如订单创建成功，扣款成功，但是库存扣减失败，物流运单生成，那么这笔订单该如何处理？这就是分布式事务要解决的核心问题。
分布式事务机制要保证不同服务之间形成一个整体性的可控的事务，业务流程上的服务除非全部成功，否则任何服务的操作失败，都会导致所有服务上操作回滚，撤销已经完成的动作。
XA是一个分布式事务协议，大致分为两部分：事务管理器和本地资源管理器，本地资源管理器基本由数据库实现，大多数关系型数据库都实现XA接口，而事务管理器作为全局事务的调度者，负责整个事务中本地资源的提交和回滚，基本原理如下：
阶段1：事务询问
事务管理器向所有的参与事务的资源管理器发送确认请求，询问是否可以执行事务提交操作，并等待各参与者的响应，如果执事务操作成功，就反馈给事务管理器表示事务可以执行，如果没有成功执行事务，就反馈事务不可以执行；
阶段2：事务提交
XA根据第一阶段每个资源管理器是否都准备提交成功，判断是要事务整体提交还是回滚，正式执行事务提交操作，并在完成提交之后释放整个事务占用的资源；事务也会存在失败情况，导致流程取消回滚；
XA事务具有强一致性，在两阶段提交的整个过程中，一直会持有资源的锁，性能不理想的缺点很明显，特别是在交易下单链路中，往往并发量很高，XA无法满足该类高并发场景。
Try(预处理)-Confirm(确认)-Cancel(取消)模式的简称TCC。
Try阶段
业务检查(一致性)及资源预留(隔离)，该阶段是一个初步操作，提交事务前的检查及预留业务资源完成；例如购票系统中的占位成功，需要在15分钟内支付；
Confirm阶段
确认执行业务操作，不在执行任何业务检查，基于Try阶段预留的业务资源，从理想状态下看只要Try成功，Confirm也会成功，因为资源的检查和锁定都已经成功；该阶段出现问题，需要重试机制或者手动处理；购票系统中的占位成功并且15分钟内支付完成，购票成功；
Cancel阶段
Cancel阶段是在业务执行错误需要回滚到状态下执行分支事务的取消，预留资源的释放；购票系统中的占位成功但是15分钟内没有支付，取消占位；
XA事务的强一致性，导致资源层的锁定；
TCC在业务层面追求最终一致性，不会长久占用资源；
现在回到模块一中的场景案例，在理想状态下流程全部成功是好的，但实际情况是突发情况很多，基于TCC模式分析上述电商的具体业务：
在TCC模式下，通常表字段的状态设计思路为：订单(支付中.已支付.取消订单)，账户(金额.冻结金额)，库存(库存.冻结库存)，物流(出库中.已出库，已撤回)，这种状态管理在开发中非常常见。
所以在TCC模式里通常会如下处理资源预留：
假设订单总额为：200，状态：支付中，则此时资源预留情况如下：
tc_account账户表：tc_total=1000，tc_ice=200，总金额1000，冻结200；
tc_inventory库存表：tc_total=100，tc_ice=20，总库存100件，冻结20件；
tc_waybill运单表：tc_state=1，运单状态，出库中；
这样下单链路上的相关资源已检查并且预留成功；
资源预留成功之后，执行资源提交执行：
tc_account账户表：tc_total=800，tc_ice=0，即订单扣款成功；
tc_inventory库存表：tc_total=80，tc_ice=0，库存消减成功；
tc_waybill运单表：tc_state=2，运单状态，已出库；
这样下单链路上的相关资源已全部提交处理成功，这是最理想的状态；
整个过程是可能执行失败的，或者用户直接自己发起回退，则要回滚整个链路上的数据：
tc_account账户表：tc_total=1000，tc_ice=0，取消账户冻结的200；
tc_inventory库存表：tc_total=100，tc_ice=0，取消库存冻结的20件；
tc_waybill运单表：tc_state=3，运单状态，已撤回；
这样下单链路上的相关数据都基于该笔订单做回退操作，恢复；
整个电商交易流程，不管是成功，还是完整的回退失败，都是需要在理想状态下，要求整个服务链路和数据是绝对正常的才行。但是在实际分布式架构下是很难保证的，所以在产品的设计上会预留很多操作入口，用来手动做事务补偿或回退操作：
大型复杂的业务系统中，直接修改数据库通常情况下是不允许的，一般核心流程会预留各种操作入口，用来处理突发状况，弥补数据的完整性，例如交易链路上，只要扣款成功，后续的数据无论如何都会补上，是不允许回滚的，当然如果没有扣款成功，订单有效期结束，该笔交易也就算做结束。
以上是“TCC事务分段提交的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！