架构设计 | 基于电商交易流程,图解TCC事务分段提交

一、场景案例简介

1、场景描述

分布式事务在业务系统中是十分常见的,最经典的场景就是电商架构中的交易业务,如图:

09-1.png

客户端通过请求订单服务,执行下单操作,实际上从订单服务上又触发了多个服务链请求,基本步骤如下:

  • 客户端请求在订单服务上创建订单;
  • 订单服务调用账户服务扣款;
  • 订单服务调用库存服务执行库存扣减;
  • 订单通过物流服务,转化为物流运单;

这套流程在电商系统中是基本业务,在实际的开发中远比这里描述的复杂。

2、服务时序图

上述1中是业务性的流程概念描述,从系统开发层面,在微服务的架构模式下,通常的时序流如下:

09-2.png

这样服务间的通信时序图在程序设计中十分常见,在分布式系统中,清楚的描述各个服务间的通信流程是十分关键的。

上图描述的交易流程是在最理想的状态下,各个服务都执行成功,但是程序是不能100%保证一直正常,经常出现如下情况:

  • 服务间通信失败;
  • 单个节点服务宕掉;
  • 服务接口执行失败;

这些都是实际开发中经常出现的问题,比如订单创建成功,扣款成功,但是库存扣减失败,物流运单生成,那么这笔订单该如何处理?这就是分布式事务要解决的核心问题。

分布式事务机制要保证不同服务之间形成一个整体性的可控的事务,业务流程上的服务除非全部成功,否则任何服务的操作失败,都会导致所有服务上操作回滚,撤销已经完成的动作。

二、TCC基础概念

1、分段提交协议

XA是一个分布式事务协议,大致分为两部分:事务管理器和本地资源管理器,本地资源管理器基本由数据库实现,大多数关系型数据库都实现XA接口,而事务管理器作为全局事务的调度者,负责整个事务中本地资源的提交和回滚,基本原理如下:

09-3.png

阶段1:事务询问

事务管理器向所有的参与事务的资源管理器发送确认请求,询问是否可以执行事务提交操作,并等待各参与者的响应,如果执事务操作成功,就反馈给事务管理器表示事务可以执行,如果没有成功执行事务,就反馈事务不可以执行;

阶段2:事务提交

XA根据第一阶段每个资源管理器是否都准备提交成功,判断是要事务整体提交还是回滚,正式执行事务提交操作,并在完成提交之后释放整个事务占用的资源;事务也会存在失败情况,导致流程取消回滚;

XA事务具有强一致性,在两阶段提交的整个过程中,一直会持有资源的锁,性能不理想的缺点很明显,特别是在交易下单链路中,往往并发量很高,XA无法满足该类高并发场景。

2、TCC概念简介

Try(预处理)-Confirm(确认)-Cancel(取消)模式的简称TCC。

Try阶段

业务检查(一致性)及资源预留(隔离),该阶段是一个初步操作,提交事务前的检查及预留业务资源完成;例如购票系统中的占位成功,需要在15分钟内支付;

Confirm阶段

确认执行业务操作,不在执行任何业务检查,基于Try阶段预留的业务资源,从理想状态下看只要Try成功,Confirm也会成功,因为资源的检查和锁定都已经成功;该阶段出现问题,需要重试机制或者手动处理;购票系统中的占位成功并且15分钟内支付完成,购票成功;

Cancel阶段

Cancel阶段是在业务执行错误需要回滚到状态下执行分支事务的取消,预留资源的释放;购票系统中的占位成功但是15分钟内没有支付,取消占位;

3、TCC对比XA

XA事务的强一致性,导致资源层的锁定;

TCC在业务层面追求最终一致性,不会长久占用资源;

三、分段事务分析

现在回到模块一中的场景案例,在理想状态下流程全部成功是好的,但实际情况是突发情况很多,基于TCC模式分析上述电商的具体业务:

1、资源预留

在TCC模式下,通常表字段的状态设计思路为:订单(支付中.已支付.取消订单),账户(金额.冻结金额),库存(库存.冻结库存),物流(出库中.已出库,已撤回),这种状态管理在开发中非常常见。

所以在TCC模式里通常会如下处理资源预留:

09-4.png

假设订单总额为: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,运单状态,出库中;

这样下单链路上的相关资源已检查并且预留成功;

2、资源提交确认

资源预留成功之后,执行资源提交执行:

09-5.png
  • tc_account账户表:tc_total=800,tc_ice=0,即订单扣款成功;
  • tc_inventory库存表:tc_total=80,tc_ice=0,库存消减成功;
  • tc_waybill运单表:tc_state=2,运单状态,已出库;

这样下单链路上的相关资源已全部提交处理成功,这是最理想的状态;

3、失败回滚

整个过程是可能执行失败的,或者用户直接自己发起回退,则要回滚整个链路上的数据:

09-6.png
  • tc_account账户表:tc_total=1000,tc_ice=0,取消账户冻结的200;
  • tc_inventory库存表:tc_total=100,tc_ice=0,取消库存冻结的20件;
  • tc_waybill运单表:tc_state=3,运单状态,已撤回;

这样下单链路上的相关数据都基于该笔订单做回退操作,恢复;

4、补偿机制

整个电商交易流程,不管是成功,还是完整的回退失败,都是需要在理想状态下,要求整个服务链路和数据是绝对正常的才行。但是在实际分布式架构下是很难保证的,所以在产品的设计上会预留很多操作入口,用来手动做事务补偿或回退操作:

09-7.png

大型复杂的业务系统中,直接修改数据库通常情况下是不允许的,一般核心流程会预留各种操作入口,用来处理突发状况,弥补数据的完整性,例如交易链路上,只要扣款成功,后续的数据无论如何都会补上,是不允许回滚的,当然如果没有扣款成功,订单有效期结束,该笔交易也就算做结束。

5、写在最后

通过电商交易的案例,和TCC模式的概念,描述了分布式事务的流程和处理思路,在开发时通常会选择现有的分布式组件来具体实现事务控制,这个流程后续再聊。


你可能感兴趣的:(架构设计 | 基于电商交易流程,图解TCC事务分段提交)