XTS分布式事务框架

简介

XTS（eXtended Transaction Service）是一个分布式事务开发框架，用来保障在大规模分布式环境下事务的最终一致性。

基于TCC设计

XTS实现

1.使用数据库持久化记录事务数据，且使用独立的事务模版，也就是单独事务

2.特别关注红线对应的 sql，这是一句 update 主事务表的 sql，而这句 sql 是在发起方的本地事务中的，这样一来就和发起方的事务绑定了，如果发起方本地事务成功，则这句 update 语句必然成功，如果发起方本地事务失败，则这句 update 语句必然失败，这样我们就可以根据 activity 表的事务记录的状态来决定这笔分布式最终的状态是成功还是失败了

3.在调用参与者前，启动单独事务插入代表这个参与者的分支事务记录，以供后续恢复使用

4.二阶段是通过 spring 提供的事务同步器实现的，如果发起方的本地事务失败，则二阶段自动回滚所有参与者，如果发起方的本地事务成功，则二阶段自动提交所有参与者。二阶段结束后，删除所有事务记录

5.服务器上的框架代码自动调用二阶段失败的话，通过提前配置由兜底服务集群进行事务捞取阶段推进

6.二阶段可配置异步化应对大促等业务场景，保证最终一致性即可

7.一二阶段通过数据库存储的上下文进行数据传递

使用：

参与者

在一阶段方法上打xts参与者注解录入commit和rollback方法，入参打上需要透传参数；

发起方

本地创建activity和action还有悬挂表，

在本地事务模版中调用xts的api开启分布式事务

api中传入事务号信息

注意点：

1.允许空回滚，拒绝空提交。业务代码保障。提交时注意幂等。

2.事务号注意业务隔离

3.悬挂问题：由于网络原因回滚请求可能先于一阶段请求到达，导致一阶段锁定资源无法释放。

解决方法1:30s重放，回滚请求延迟30s再执行，等待一阶段请求，一般30s都没到说明已经丢失。

解决方法2:双插，回滚记录插入回滚表，一阶段请求到来时检测到回滚表已有记录则不执行。通过切面写入和检查。插入时使用事务id+框架生成action唯一id，因为同一事务可能调用多次同一个参与者。

业务问题：

        碰到过的隔离问题。本系统作为参与者一，发起者发起了两次xts事务，第一次xts事务失败，本系统回滚成功，但是参与者二系统回滚失败。发起者发起第二次xts事务，第二次xts事务成功，参与者均正常提交。但是第一次失败的回滚请求，在第二次xts事务成功之后又打到了本系统，由于上游的两次事务为同一个单号重试，本系统以上游单号作为幂等识别，在处理回滚请求时直接根据上游单号查到了第二次提交的数据，所以回滚处理将数据删除了。上下游正常处理，但是本系统数据没了。根本原因是没能区分两次不同的事务。

解决方案：

插入时写入业务隔离关联关系，如果查询为空就插入，否则以查询为准。如果发现事件未处理到终态，说明有相同事件的其他事务正在执行，直接报错，否则返回事件最终结果作为幂等。因有其他事务执行中而被报错返回的事务因为未生成相关数据，所以在回滚时也不做相关数据的删除。