摘要: 传统的基于数据库本地事务的解决方案只能保障单个服务的一次处理具备原子性、隔离性、一致性与持久性，但无法保障多个分布服务间处理的一致性。因此，我们必须建立一套分布式服务处理之间的协调机制，保障分布式 ...
为了能够有效的让框架进行分布式事务的提交、回滚等动作，框架需要在整个两阶段执行过程中记录下足够的信息，设计了两张表来记录相关信息： 分布式业务控制活动主表：记录了全局事务的活动状态； 原子业务活动表：记录了原子业务活动的状态； 我们用一个例子来说明： 看一个典型的分布式事务场景。 业务场景描述: 用户购买商品，使用支付宝余额支付； 测试方案 分析步骤 角色定位 各分支的业务活动记录状态 梳理业务各个场景 验证梳理场景 恢复&回查机制 角色定位 首先测试人员需要分析所测试的系统处于分布式事务中的哪一个环节中,是处于事务的发起者,还是事务的参与者,不同的角色的定位对于测试分析角度不同,主要有以下的区别： 发起者： 分为同库/异库模式，主要区分是控制全局事务状态的主事务记录是否持久化在自己系统的db中； 参与者： 分为本地/远程模式，主要区分是是否可以创建嵌套的分布式事务； 各分支的业务活动记录状态 主事务记录： 根据业务场景的不同，主事务记录状态也会相应改变，主要的状态机变化如图所示，测试人员需要模拟业务场景来验证状态机的迁转是否正确； 同库：初始状态：I;提交成功：C;提交失败：I 异库：初始状态：U;提交成功：U;提交失败：U |
