分布式事务-简介+案例

什么是分布式事务？

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

相较于非分布式系统的事务，分布式事务由于在多JVM中进行事务管理，无法直接通过控制提交来达到事务管理，所以在分布式事务中，我们引入了两段式提交协议，为了实现分布式事务，必须使用一种协议在分布式事务的各个参与者之间传递事务上下文信息，IIOP便是这种协议。这就要求不同开发商开发的事务参与者必须支持一种标准协议，才能实现分布式的事务。

什么是两段式提交协议？

阶段一：开始向事务涉及到的全部资源发送提交前信息。此时，事务涉及到的资源还有最后一次机会来异常结束事务。如果任意一个资源决定异常结束事务，则整个事务取消，不会进行资源的更新。否则，事务将正常执行，除非发生灾难性的失败。为了防止会发生灾难性的失败，所有资源的更新都会写入到日志中。这些日志是永久性的，因此，这些日志会幸免于难并且在失败之后可以重新对所有资源进行更新。

阶段二：只在阶段一没有异常结束的时候才会发生。此时，所有能被定位和单独控制的资源管理器都将开始执行真正的数据更新。在分布式事务两阶段提交协议中，有一个主事务管理器负责充当分布式事务协调器的角色。事务协调器负责整个事务并使之与网络中的其他事务管理器协同工作。

下面我们以TCC分布式事务处理订单支付为例详解分布式事务：

在这个例子中，我们在订单支付后会有下面的动作：

• 修改订单状态为已支付
• 扣除库存
• 增加会员积分
• 创建销售出货单

在这个过程中，每个微服务系统之间需要进行服务调用完成用于的订单支付，当系统完成支付动作后，会返回给用户订单信息。

但是如果我们设计的微服务系统没有考虑到分布式事务的问题，那么在高并发的情况下，库存系统会出现库存数量异常，这样即使我们完成了这个订单，但是会出现卖出去的比库存多的情况，造成不必要的麻烦。

这时我们需要使用分布式事务进行事务处理，那么我们该怎么实现分布式事务呢？

第一阶段：Try

代码：

public class OrderService {
    // 库存服务
    @Autowired
    private InventoryService inventoryService;
    // 积分服务
    @Autowired
    private CreditService creditService;
    // 仓储服务
    @Autowired
    private WmsService wmsService;
    // 对这个订单完成支付
    public void pay(){
        //对本地的的订单数据库修改订单状态为"已支付"
        orderDAO.updateStatus(OrderStatus.PAYED);
        //调用库存服务扣减库存
        inventoryService.reduceStock();
        //调用积分服务增加积分
        creditService.addCredit();
        //调用仓储服务通知发货
        wmsService.saleDelivery();
    }
}

我们分别调用各个接口来修改个系统的状态

第二阶段：confirm

这个时候，就需要依靠 TCC 分布式事务框架来推动后续的执行了。这里简单提一句，如果你要玩儿 TCC 分布式事务，必须引入一款 TCC 分布式事务框架，比如国内开源的 ByteTCC、Himly、TCC-transaction。

如果你在各个服务里引入了一个 TCC 分布式事务的框架，订单服务里内嵌的那个 TCC 分布式事务框架可以感知到，各个服务的 Try 操作都成功了。

此时，TCC 分布式事务框架会控制进入 TCC 下一个阶段，第一个 C 阶段，也就是 Confirm 阶段。

库存服务也是类似的，你可以有一个 InventoryServiceConfirm 类，里面提供一个 reduceStock() 接口的 Confirm 逻辑，这里就是将之前冻结库存字段的 2 个库存扣掉变为 0。

这样的话，可销售库存之前就已经变为 98 了，现在冻结的 2 个库存也没了，那就正式完成了库存的扣减。

积分服务也是类似的，可以在积分服务里提供一个 CreditServiceConfirm 类，里面有一个 addCredit() 接口的 Confirm 逻辑，就是将预增加字段的 10 个积分扣掉，然后加入实际的会员积分字段中，从 1190 变为 1120。

仓储服务也是类似，可以在仓储服务中提供一个 WmsServiceConfirm 类，提供一个 saleDelivery() 接口的 Confirm 逻辑，将销售出库单的状态正式修改为“已创建”，可以供仓储管理人员查看和使用，而不是停留在之前的中间状态“UNKNOWN”了。

好了，上面各种服务的 Confirm 的逻辑都实现好了，一旦订单服务里面的 TCC 分布式事务框架感知到各个服务的 Try 阶段都成功了以后，就会执行各个服务的 Confirm 逻辑，完成所有业务逻辑的执行。

第三阶段：cancel

当其中某一个服务出现异常，或者业务上不允许支付成功时，TCC事务框架会感知到，对整个TCC分布式事务进行回滚

也就是说，会执行各个服务的第二个 C 阶段，Cancel 阶段。同样，为了实现这个 Cancel 阶段，各个服务还得加一些代码。

首先订单服务，它得提供一个 OrderServiceCancel 的类，在里面有一个 pay() 接口的 Cancel 逻辑，就是可以将订单的状态设置为“CANCELED”，也就是这个订单的状态是已取消。

库存服务也是同理，可以提供 reduceStock() 的 Cancel 逻辑，就是将冻结库存扣减掉 2，加回到可销售库存里去，98 + 2 = 100。

积分服务也需要提供 addCredit() 接口的 Cancel 逻辑，将预增加积分字段的 10 个积分扣减掉。

仓储服务也需要提供一个 saleDelivery() 接口的 Cancel 逻辑，将销售出库单的状态修改为“CANCELED”设置为已取消。

然后这个时候，订单服务的 TCC 分布式事务框架只要感知到了任何一个服务的 Try 逻辑失败了，就会跟各个服务内的 TCC 分布式事务框架进行通信，然后调用各个服务的 Cancel 逻辑。

 

这样我们就完成了对分布式系统的事务架构。

总结：

在我们面试的时候，一定要找准分布式事务的重点在于事务的分段式提交，根据confirm 或是 cancel 来进行事务的提交或是回滚

• 先是服务调用链路依次执行 Try 逻辑。
• 如果都正常的话，TCC 分布式事务框架推进执行 Confirm 逻辑，完成整个事务。
• 如果某个服务的 Try 逻辑有问题，TCC 分布式事务框架感知到之后就会推进执行各个服务的 Cancel 逻辑，撤销之前执行的各种操作。