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事务模型
- TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
- XID 在微服务调用链路的上下文中传播。
- RM 向 TC 注册分支事务，接着执行这个分支事务并提交（重点：RM在第一阶段就已经执行了本地事务的提交/回滚），最后将执行结果汇报给TC。
- TM 根据 TC 中所有的分支事务的执行情况，发起全局提交或回滚决议。
- TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。
欢迎关注：叮铛的公众号，套路三联。。。。。。
回复 8888可以领取面试资料
