分布式事务及详解

参照:https://mp.weixin.qq.com/s/KxMBoexptyydagnsfAqsoA
https://mp.weixin.qq.com/s/Mcx13fPfAHgWD3kaErH9Pg
多线程下Spring事务:https://mp.weixin.qq.com/s/JEA_iQ2BuSASYiiOWK7hJQ
在分布式系统、微服务架构大行其道的今天,服务间互相调用出现失败已经成为常态。
场景

为什么有分布式事务,场景很多,如订单支付成功,调用各种微服务完成整个订单,订单状态、积分、优惠券、库存等需要调用不同微服务完成。再比如跨银行转操作就涉及调用两个异地银行服务。

CAP
要实现分布式事务需要搞清楚一个理论,CAP理论。
一个分布式系统不可能同时满足一致性,可用性和分区容错性这个三个基本需求,最多只能同时满足其中两项
一致性(C):数据在多个副本之间是否能够保持一致的特性。
可用性(A):是指系统提供的服务必须一致处于可用状态,对于每一个用户的请求总是在有限的时间内返回结果,超过时间就认为系统是不可用的。
分区容错性(P):分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非整个网络环境都发生故障。
更多详细内容请参见:CAP定律、BASE理论

如何处理异常,如何保证数据一致性,成为微服务设计过程中,绕不开的一个难题。在不同的业务场景下,解决方案会有所差异,常见的方式有:

1.阻塞式重试;
阻塞式重试也是分布式系统中常用的方法,不引入系统复杂度实现分布式事务。
执行流程一般遵循本地事务完成,再调用B服务,B服务失败或者超时会进行多次调用。根据场景和业务需要一般会调用3次,都失败会进行告警日志或者告警邮件或者保存错误信息到数据库,本地事务根据业务场景进行回滚或者不回滚。
存在问题:
● 调用B服务成功,因为网络原因,没有返回正确的信息,造成信息不对称,注意一点需要B服务保证幂等行,否则会造成重复数据。
● 多次重试会造成上下游系统资源浪费。

int count = userService.insertUser(vo);

if (count > 0) {
    for (int i = 0; i < 3; i++) {
        Response response = integralService.save(10);
        if (!response.isOk()) {
            Thread.sleep(2000);
        } else {
            break;
        }       
    }
}

2.2PC、3PC 传统事务;
二阶段提交协议是将事务的提交过程分成提交事务请求和执行事务提交两个阶段进行处理。需要协调者支持。

2pc:
成功

阶段1:提交事务请求

  1. 执行事务:各参与者节点执行事务操作,并将Undo和Redo信息记入事务日志中
  2. 如果参与者成功执事务操作,就反馈给协调者Yes响应,表示事物可以执行,如果没有成功执行事务,就反馈给协调者No响应,表示事务不可以执行。
    阶段二:执行事务提交
  3. 假如协调者从所有的参与者或得反馈都是Yes响应,那么就会执行事务提交。
  4. 发送提交请求:协调者向所有参与者节点发出Commit请求
  5. 事务提交:参与者接受到Commit请求后,会正式执行事务提交操作,并在完成提交之后放弃整个事务执行期间占用的事务资源
  6. 反馈事务提交结果:参与者在完成事物提交之后,向协调者发送ACK消息
  7. 完成事务:协调者接收到所有参与者反馈的ACK消息后,完成事务

失败

中断事务
● 假如任何一个参与者向协调者反馈了No响应,或者在等待超时之后,协调者尚无法接收到所有参与者的反馈响应,那么就中断事务。
● 发送回滚请求:协调者向所有参与者节点发出Rollback请求
● 事务回滚:参与者接收到Rollback请求后,会利用其在阶段一种记录的Undo信息执行事物回滚操作,并在完成回滚之后释放事务执行期间占用的资源。
● 反馈事务回滚结果:参与则在完成事务回滚之后,向协调者发送ACK消息
● 中断事务:协调者接收到所有参与者反馈的ACk消息后,完成事务中断
优缺点
● 原理简单,实现方便
● 缺点是同步阻塞,单点问题,脑裂,保守
3pc
3PC 把 2PC 的准备阶段再次一分为二,这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段
改进:1 将prepare拆分成cancommit和precommit,减少资源浪费 2 引入超时机制。同时在协调者和参与者中都引入超时机制,等待超时后,继续commit

3.使用队列,后台异步处理;
4.TCC 补偿事务;
5.本地消息表(异步确保);
6.MQ 事务https://rocketmq.apache.org/zh/docs/featureBehavior/04transactionmessage/。

7.开源组件Seata:http://seata.io/zh-cn
Seata是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案

seata架构中的三个角色
1、TC(Trasaction Cordornator) 事务协调者,维护全局和分支事务的状态,驱动全局事务提交或回滚。
2、TM(Transaction Manager) 事务管理者,定义全局事务的范围,开始全局事务、提交或回滚全局事务。
3、RM(Resource Manager) 资源管理者,管理分支事务处理的资源,与TC交互以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。

扣减库存
https://mp.weixin.qq.com/s/F0TPkVY2VERGwUnVX2QGiw#/

posted @ 2021-11-26 10:13  倔强的老铁  阅读(103)  评论(0编辑  收藏  举报