全局分布式事务GTS原理以及架构（一）

1.微服务发展

随着业务发展单体应用越来越负载，需要将单个应用拆分为若干个功能简单、松耦合的服务，这样可降低开发、维护的成本，增强扩展性以及敏捷开发。微服务框架也非常多Dubbo、Springcloud、thrift、grpc等。微服务存在的问题：

1、微服务之间的通信以及故障处理

2、原子交易，多个服务之间的调用如何维护数据的最终一致性

3、服务编排：发现、部署和扩容

问题1，解决策略，rpc框架的使用：dubbo多种协议，springcloud的restful

问题2，分布式事务，现在没有通用的解决方式

问题3，服务编排Mesos、docker swarm、k8s等

2.传统分布式事务

2.1 XA规范定义了AP、TM、RM之间的接口

 

大体流程：

1）AP向TM创建全局事务，TM向AP返回全局事务ID

2）AP使用全局事务ID，访问RM资源，RM向TM注册，TM返回分支事务ID

3）AP向TM发出全局事务提交请求，TM与RM通信，RM提交事务，全部完成后向AP提交

二阶提交协议和三阶提交协议就是根据这一思想衍生出来的。可以说二阶段提交其实就是实现XA分布式事务的关键(确切地说：两阶段提交主要保证了分布式事务的原子性：即所有结点要么全做要么全不做)

缺点：

1）同步阻塞，所有的节点的事务都是阻塞的，只有全部提交之后才能释放所有占有的资源

2）数据不一致，第二阶段提交的协调者向参与者发送请求后，部分参与者由于网络异常导致没有接收到commit请求，这样会导致部分参与者已经提交，另一部分没有提交出现数据不一致的现象

2.2 补偿事务

TCC主要采用的补偿机制，针对每一个操作搜需要注册一个确认和补偿操作，tcc分为三个阶段：

try：主要的业务流程

commit：业务系统确认提交

cancel：执行错误之后，回滚业务

缺点：业务代码侵入型太强，需要写补偿代码

2.3 可靠性消息投递

流程：

1）消费者向MQ发送消息，出入prepare阶段

2）消费者执行本地事务逻辑

3）本地事务执行成功后，向MQ返送commit/rollback操作

4）MQ收到commit/rollback后决定消息是否投递

5）消费者消费消息执行本地事务

优点：

降低业务系统的耦合，

缺点：

两次网络请求，需要实现消息的回查操作确认事务提交情况

2.4 Sagas事务模型

 

1. TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
2. XID 在微服务调用链路的上下文中传播。
3. RM 向 TC 注册分支事务，接着执行这个分支事务并提交（重点：RM在第一阶段就已经执行了本地事务的提交/回滚），最后将执行结果汇报给TC。
4. TM 根据 TC 中所有的分支事务的执行情况，发起全局提交或回滚决议。
5. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

 

欢迎关注：叮铛的公众号，套路三联。。。。。。

回复  8888可以领取面试资料