一.目录

前言

内容

结语

二. 前言

本资料来源于项目资料！

三.内容

关键词：*分布式事务、数据一致性、最终一致性*

摘 要：*本说明书针对软件内部模块及流程做了详细说明，可作为软件开发者、系统测试者及部门项目经理等人员的参考文档。*

1 *简介*

1.1 *目的*

随着业务的发展，支付系统必须支持大数据量、高并发等特性，同时必须保持数据的强一致性。为了满足需求，系统普遍采用分库分表等技术，因此一次业务操作会涉及到调用不同的数据资源，为了保持数据的强一致性，必须有分布式事务系统支持，而现有基于XA规范实现的分布式事务系统不能满足高并发场景。本文档描述了一种可替代的分布式事务系统简单设计方案。

1.2 *范围*

本文档描述内容包括：系统领域模型、系统结构组成、业务处理流程描述。

1.2.1 *软件名称*

DTS

1.2.2 *软件功能*

分布式事务系统简单实现，支持对多数据源的操作，同时保证数据的一致性，对于数据一致性，系统保证最终一致性，因此当发生不可逆异常时，从不同业务子系统看到的数据会具有短暂的不一致性，但系统具有自动恢复功能，会保证数据的最终一致性。由于系统保证的是数据的最终一致性，因此需要业务系统自身设计业务的调用顺序，从而保证数据一致性的延后不会对系统产生影响。例如：申请转账业务，需要先调用账务系统记账，再产生转账记录，如果调用顺序相反，那么当账务系统记账失败，并且回滚操作延后，会产生不可预料的结果。

具体针对支付系统中，涉及到账务系统扣减金额的业务必须先调用账务系统，再处理业务系统（失败处理方式为回滚CANCEL）；涉及到账务系统增加金额的业务必须先处理业务系统，再调用账务系统（失败处理方式为重新提交RECONFIRM）。

2 *设计描述*

2.1 *设计方案*

2.1.1 *领域模型*

一个完整的业务活动由一个主业务活动和若干分支服务组成，主业务活动负责发起并完成整个业务活动。

主要有两个领域模型：主业务活动（Business_Activity）、分支服务（Business_Action）。主业务活动记录整个事务当前处理状态、创建时间、失败处理方式等属性，分支服务记录分支活动的服务名、方法名（提交或回滚方法）、方法对应参数的序列化值等必要属性。

主业务活动属性如下：

*属性名称*	*描述*
ID标识（TX_ID）	全局唯一主业务活动ID标识
状态	主业务活动当前处理状态（BEGIN：开始状态  END：业务活动结束）
创建时间	主业务活动创建时间
失败处理方式	业务活动处理失败，未结束时的处理机制CANCEL：回滚，已完成的分支服务执行回滚操作RECONFIRM：重复提交，未完成的分支服务执行提交操作
分支服务个数	分支服务个数

分支服务属性如下：

*属性名称*	*描述*
分支服务ID	分支服务ID标识
主业务活动ID	所属主业务活动ID
服务名称	即分支服务名，可通过该服务名获得服务调用
方法名	分支服务方法名，执行提交或回滚动作的方法名
参数序列化值	提交或回滚方法对应参数的序列化值，通过该值进行反序列化后可获得实体对象

当前分支服务属性如下：

*属性名称*	*描述*
主业务活动ID	所属主业务活动ID
服务名称	分支服务名
提交方法名
服务状态	CONFIRM：服务已提交完成CANCEL：服务已回滚

2.1.2 *业务处理流程*

2.1.2.1 *规则约束*

1、 主业务活动记录与分支服务记录同库；

2、 当前分支服务记录与被调用的分支服务同库，保证事务的一致性；

3、 各分支服务提供查询接口，查询当前分支服务状态；

4、 各分支服务提交与回滚接口要求满足幂等性；

5、 通过方法注解、拦截器等方式实现主业务活动记录和分支服务记录的注册存储，对业务的侵入性减少到最小。

2.1.2.2 *主流程*

1、 开始业务活动并注册各分支服务

创建主业务活动记录，创建各分支服务记录，通过方法注解的方式获取主业务活动必要属性，通过方法注解方式获取各参与分支服务的必要属性。

2、 服务提交阶段

各分支服务依次执行如下步骤：

创建分支服务记录，状态为CONFIRM；

执行分支服务业务逻辑；

上述操作资源同库，所以为原子操作，保证了事务一致性。

3、 结束主业务活动

主业务活动记录更改为END。

4、 异常处理

第1步发生异常，整个业务活动失败，抛异常给业务活动调用者；

第2步发生异常或执行不成功，根据失败处理方式来决定是继续提交还是回滚；

第3步发生异常，不作处理，业务活动正常完成；

2.1.2.3 *异常流程（定时任务）*

定时任务，用来处理各种超时未完成的业务活动（即状态不为END的超时主业务记录），如：远程服务调用返回时网络异常、JAVA进程异常退出、服务重启、机器宕机等。

1、 查询超时未完成主业务活动记录（状态不为END）及分支服务记录；

2、 调用各分支服务查询当前服务状态；

3、 若各分支服务记录都不存在、或各分支服务状态均为CONFIRM或CANCEL，则更新主业务活动状态为END；

4、 其它情况：

若失败处理方式为CANCEL，依次调用各分支服务的回滚操作（服务状态已经为CANCEL的不用调用），更新主业务活动状态为END；

若失败处理方式为RECONFIRM，依次调用各分支服务的提交操作（服务状态已经为CONFIRM的不用调用），更新主业务活动状态为END；

5、 异常处理：

上述步骤中若发生异常，均不做处理，等待下次任务调用处理

四.结语

本资料来源于项目资料！