淘先锋技术网

首页 1 2 3 4 5 6 7

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事务模型

Seata 应用迁移上云

 

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

 

欢迎关注:叮铛的公众号,套路三联。。。。。。

回复  8888可以领取面试资料