分布式事务解决方案

业务场景：

    当我们系统一个操作需要设计到多个业务，被大家举烂的例子是银行转账，分为两个操作，

    1、本地的提款操作。

    2、远程的存款操作。

    以上两个操作构成了一个分布式的事务，如何保证其一致性，

前提：

    业务具有逆向操作：如 提款操作的逆向操作为存款，存款的逆向操作是取款

    逆操作的幂等性（多次执行结果不变）

幂等性：

    幂等性就是多次重复执行结果不变，例如例子中转账操作，本地取款，异地存款，当异地存款出现异常时，需要调用本地存款回滚，要求我重复多次本地存款操作 本地不会出现金额重复增多的情况，这就是幂等性。

一般有两种处理方式

    1、准实时的事务补偿机制

    2、基于消息的最终一致性

执行过程

   1、准实时的事务补偿机制

        首先调用取款服务，完全调用成功并返回，数据已经持久化。

        然后调用异地的存款服务，如果也调用成功，则本身无任何问题。

        如果调用失败，一般抛出异常或者返回错误码，则需要调用本地注册的逆向服务（本地存款服务），

        如果本地存款服务调用失败，则必须考虑重试，根据设置重试次数进行重试。

        如果约定重试次数仍然不成功，则必须log到完整的不一致信息，人工介入修改。

   2、基于消息的最终一致性

        首先调用取款服务，完全调用成功并返回，数据已经持久化。

        然后异步发送存款消息到消息中间件，并持久化。两步完成表示事务成功。

        一般发送消息都在本地，事务很容易控制。

        但此时对方并没有实际存入，需要等待消息中间件进行存入的操作，如果失败需要根据设置重试次数进行重试。

        如果约定重试次数仍然不成功，则必须log到完整的不一致信息，人工介入修改。

总结

    1、第一种基于事务补偿机制，能够达到准实时的事务，但需要更多的代码，复杂度提升。

    2、基于消息的最终一致性，在取款和存款之间存在一个中间状态，但可以不用关心。代码复杂度降低。

具体业务仍然需要看你的业务场景，是否需要准实时，或许最终一致性也可以达到场景需求。