广州住房保障城市建设局网站,四川最新情况最新消息今天,做企业网站那家好,wordpress微现场文章目录 一.为什么引入分布式事务?二.理论基础1.CAP定理2.BASE理论 三.Seata1.微服务集成Seata2.XA模式(掌握)3.AT模式(重点)4.TCC模式(重点)5.Saga模式(了解) 四.四种模式对比五.Seata高可用 一.为什么引入分布式事务?
事务的ACID原则 在大型的微服务项目中,每一个微服务都… 文章目录 一.为什么引入分布式事务?二.理论基础1.CAP定理2.BASE理论 三.Seata1.微服务集成Seata2.XA模式(掌握)3.AT模式(重点)4.TCC模式(重点)5.Saga模式(了解) 四.四种模式对比五.Seata高可用 一.为什么引入分布式事务?
事务的ACID原则 在大型的微服务项目中,每一个微服务都可能包含一个独立的数据库,当单个数据库的操作由于某种原因进行回滚操作了,其他数据库也会进行回滚操作吗?
设想以下案例:
微服务下单业务在下单时会调用订单服务创建订单并写入数据库。然后订单服务调用账户服务和库存服务
账户服务负责扣减用户余额库存服务负责扣减商品库存 但是当库存数据库中的库存数量小于扣减数呢?库存数据库会回滚,但是账户服务的数据库和订单服务的数据库依旧执行成功,这并不是我们希望看到的效果 所以说在分布式系统下一个业务跨越多个服务或数据源每个服务都是一个分支事务要保证所有分支事务最终状态一致这样的事务就是分布式事务。
二.理论基础
1.CAP定理
1998年加州大学的计算机科学家 Eric Brewer 提出分布式系统有三个指标
Consistency一致性Availability可用性Partition tolerance 分区容错性
Eric Brewer 说分布式系统无法同时满足这三个指标。 这个结论就叫做 CAP 定理。 CAP定理- Consistency
Consistency一致性用户访问分布式系统中的任意节点得到的数据必须一致
当进行数据更改的时候,node01的数据必须同步更新给node02,不然会导致查询出的数据不一致 CAP定理- Availability
Availability 可用性用户访问集群中的任意健康节点必须能得到响应而不是超时或拒绝 CAP定理-Partition tolerance
Partition分区因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接形成独立分区。
Tolerance容错在集群出现分区时整个系统也要持续对外提供服务
所以说,Partition tolerance(分区容错):即系统在网络发生故障或分区时仍然能够保持正常的运行 假设ode03和node02之间出现了网络故障,node01和node02是一个分区,而node03是一个分区
当出现分区时,如果想保证数据的一致性即Consistency,那么就必须等待node02和node03之间的网络恢复,从而node02能将数据同步给node03,但此时不能满足Availability 可用性,因为在等待网络恢复过程中,nbode03不能够进行访问
如果想保证Availability 可用性,那么node02分区和node03分区的数据就会不一致,从而出现不一致性,即没有满足Consistency一致性
可以发现,由于两两互斥,所以三种特性都不能同时满足
思考elasticsearch集群是CP还是AP
ES集群出现分区时故障节点会被剔除集群数据分片会重新分配到其它节点保证数据一致。因此是低可用性高一致性属于CP
2.BASE理论
BASE理论是对CAP的一种解决思路包含三个思想 Basically Available 基本可用分布式系统在出现故障时允许损失部分可用性即保证核心可用。 Soft State软状态在一定时间内允许出现中间状态比如临时的不一致状态。 Eventually Consistent最终一致性虽然无法保证强一致性但是在软状态结束后最终达到数据一致。 而分布式事务最大的问题是各个子事务的一致性问题因此可以借鉴CAP定理和BASE理论
AP模式各子事务分别执行和提交允许出现结果不一致然后采用弥补措施恢复数据即可实现最终一致。CP模式各个子事务执行后互相等待同时提交同时回滚达成强一致。但事务等待过程中处于弱可用状态。 分布式事务模型
解决分布式事务各个子系统之间必须能感知到彼此的事务状态才能保证状态一致因此需要一个事务协调者来协调每一个事务的参与者子系统事务。
这里的子系统事务称为分支事务有关联的各个分支事务在一起称为全局事务 三.Seata
Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务为用户打造一站式的分布式解决方案。
官网地址: http://seata.io/其中的文档、播客中提供了大量的使用说明、源码分析。
Seata架构
Seata事务管理中有三个重要的角色 TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态协调全局事务提交或回滚。 TM (Transaction Manager) - 事务管理器定义全局事务的范围、开始全局事务、提交或回滚全局事务。 RM (Resource Manager) - 资源管理器管理分支事务处理的资源与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。 Seata提供了四种不同的分布式事务解决方案 XA模式强一致性分阶段事务模式牺牲了一定的可用性无业务侵入 TCC模式最终一致的分阶段事务模式有业务侵入 AT模式最终一致的分阶段事务模式无业务侵入也是Seata的默认模式 SAGA模式长事务模式有业务侵入 部署TC服务
需要注意:在配置Seata配置文件的时候,group和dataId必须和nacos配置管理的Data Id和Group一致 1.微服务集成Seata
1.引入seata相关依赖 dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-seata/artifactIdexclusions!--版本较低1.3.0因此排除--exclusionartifactIdseata-spring-boot-starter/artifactIdgroupIdio.seata/groupId/exclusion/exclusions/dependency!--seata starter 采用1.4.2版本--dependencygroupIdio.seata/groupIdartifactIdseata-spring-boot-starter/artifactIdversion${seata.version}/version/dependency2.配置application.yml让微服务通过注册中心找到seata-tc-server
seata:registry:# TC服务注册中心的配置微服务根据这些信息去注册中心获取tc服务地址# 参考tc服务自己的registry.conf中的配置# 包括地址、namespace、group、application-name 、clustertype: nacosnacos: # tcserver-addr: 127.0.0.1:8848namespace: group: DEFAULT_GROUPapplication: seata-tc-server # tc服务在nacos中的服务名称username: nacospassword: nacostx-service-group: seata-demo # 事务组根据这个获取tc服务的cluster名称service:vgroup-mapping: # 事务组与TC服务cluster的映射关系seata-demo: SH2.XA模式(掌握)
XA模式原理
XA 规范 是 X/Open 组织定义的分布式事务处理DTPDistributed Transaction Processing标准XA 规范 描述了全局的TM与局部的RM之间的接口几乎所有主流的数据库都对 XA 规范 提供了支持。 seata的XA模式做了一些调整但大体相似
RM一阶段的工作 注册分支事务到TC执行分支业务sql但不提交报告执行状态到TC TC二阶段的工作 TC检测各分支事务执行状态 如果都成功通知所有RM提交事务如果有失败通知所有RM回滚事务 RM二阶段的工作 接收TC指令提交或回滚事务 XA模式的优点是什么
事务的强一致性满足ACID原则。常用数据库都支持实现简单并且没有代码侵入
XA模式的缺点是什么
因为一阶段需要锁定数据库资源等待二阶段结束才释放性能较差,低可用数据操作导致的不一致需要进行回滚操作,故需要依赖关系型数据库实现事务
实现XA模式
Seata的starter已经完成了XA模式的自动装配实现非常简单步骤如下
1.修改application.yml文件每个参与事务的微服务开启XA模式 2.给发起全局事务的入口方法添加 GlobalTransactional注解本例中是OrderServiceImpl中的create方法
3.AT模式(重点)
AT模式原理
AT模式同样是分阶段提交的事务模型不过缺弥补了XA模型中资源锁定周期过长的缺陷。
阶段一RM的工作 注册分支事务 记录undo-log数据快照 执行业务sql并提交 报告事务状态
阶段二提交时RM的工作
删除undo-log即可
阶段二回滚时RM的工作
根据undo-log恢复数据到更新前 例如
一个分支业务的SQL是这样的update tb_account set money money - 10 where id 1 AT模式与XA模式最大的区别是什么
XA模式一阶段不提交事务锁定资源AT模式一阶段直接提交不锁定资源。
XA模式依赖数据库机制实现回滚AT模式利用数据快照实现数据回滚。
XA模式强一致AT模式最终一致 AT模式的脏写问题
假设有以下场景:
事务1和事务2都受AT模式的Seata管理,当事务1更改数据库中的字段时(例如money字段),首先是获取了DB锁,保存了此刻的字段值快照,当执行完业务后归还了DB锁并提交了事务,但事务2紧接着获得了DB锁操作了相同的字段,也提交了事务,此时字段(money)就进行了两次更改,但是事务1并不知道发生了除它以外的操作,更糟糕的是TC此时发现数据库操作失败需要进行回滚,事务1就立马按照数据快照的数据进行更新数据库,从而导致产生了脏写问题 那么该如何避免脏写问题呢? AT模式的写隔离
所谓的写隔离其实就是对全局事务增加了全局锁,全局锁由TC记录,当前正在操作某行数据的事务该事务持有全局锁具备执行权。
还是刚才的例子,当业务1要提交事务之前,事务1拿到了全局锁,拥有这个字段的执行权(即受AT模式管理的Seata中的所有事务,对这个字段的操作权有且仅有事务1),TC会将事务,表,字段等信息存入数据库表中,当事务2想要操作相同字段并且提交的时候,它也需要获取这个字段的全局锁,但此时发现操作这个字段的全局锁已经有事务拿到了,事务2就只能进行等待状态(等待时间默认为30次,间隔为10ms,这样做是为了避免事务1进行回滚而事务2占用DB锁,但是事务1又占用了全局锁所造成的死锁状态),当等待时间过去后,事务1拿到了DB锁操作数据库回滚完成,释放全局锁,这个中间字段只有事务1在进行操作,成功避免了脏写问题
但是如果不是受Seata管理的事务2呢?因为不受Seata管理就没有全局锁,事务2就可以自由操作和事务1相同的字段了(前提是拿到DB锁)
AT模式中引入了两个快照机制,一个是before-image(操作前的数据快照)和after-image(操作后的数据快照),当事务1进行回滚的时候会判断after-image是否和现在的字段数据一致,一致则回滚,不一致则记录异常,发送警告,人工介入 AT模式的优点 一阶段完成直接提交事务释放数据库资源性能比较好 利用全局锁实现读写隔离 没有代码侵入框架自动完成回滚和提交
AT模式的缺点 两阶段之间属于软状态属于最终一致 框架的快照功能会影响性能但比XA模式要好很多 实现AT模式
AT模式中的快照生成、回滚等动作都是由框架自动完成没有任何代码侵入因此实现非常简单。
1.导入Sql文件seata-at.sql其中lock_table导入到TC服务关联的数据库undo_log表导入到微服务关联的数据库
2.修改application.yml文件将事务模式修改为AT模式即可
seata:data-source-proxy-mode: AT # 开启数据源代理的AT模式4.TCC模式(重点)
TCC模式原理
TCC模式与AT模式非常相似每阶段都是独立事务不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法 Try资源的检测和预留 Confirm完成资源操作业务要求 Try 成功 Confirm 一定要能成功。 Cancel预留资源释放可以理解为try的反向操作。
TCC模式冻结机制与AT模式中的快照恢复机制有很大的相同点:
TCC冻结机制其实是相当于恢复操作的数据(例如金额),而AT模式快照恢复是恢复全部的数据(操作之前的数据),TCC实现了不需要全局锁进行隔离取之代替的是冻结(相当于对操作的数据绑定了一个事务).TCC模式可以和AT模式混用 TCC的工作模型图 需要注意的是Confirm实现的不是提交具体的事务,提交具体的事务其实在资源预留已经做完了,Confirm实现的是删除冻结记录操作,相当于TC确认所有事务执行无误,提交的全局事务
总结:
TCC的优点是什么 一阶段完成直接提交事务释放数据库资源性能好 相比AT模型无需生成快照无需使用全局锁性能最强 不依赖数据库事务而是依赖补偿操作可以用于非事务型数据库
TCC的缺点是什么 有代码侵入需要人为编写try、Confirm和Cancel接口太麻烦 软状态事务是最终一致 需要考虑Confirm和Cancel的失败情况做好幂等处理 补充:
1.什么是幂等?
幂等是指对同一操作的多次执行具有相同的效果不会导致不一致或意外的结果。换句话说如果一个操作是幂等的那么无论执行多少次最终的状态都是相同的。
2.在TCC中的空回滚和业务悬挂
空回滚:当某分支事务的try阶段阻塞时可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作这时cancel不能做回滚就是空回滚。
业务悬挂:对于已经空回滚的业务如果以后继续执行try就永远不可能confirm或cancel这就是业务悬挂。应当阻止执行空回滚后的try操作避免悬挂
简单来说,空回滚就是在业务还没执行之前就进行回滚了,业务悬挂是在空回滚后继续执行了try逻辑 案例:改造account-service服务利用TCC实现分布式事务 业务分析:
为了实现空回滚、防止业务悬挂以及幂等性要求。我们必须在数据库记录冻结金额的同时记录当前事务id和执行状态为此我们设计了一张表 业务逻辑: 实现方法:
1.声明TCC接口
TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明语法如下
LocalTCC
public interface AccountTCCService {/*** Try逻辑TwoPhaseBusinessAction中的name属性要与当前方法名一致用于指定Try逻辑对应的方法* param userId* param money*/TwoPhaseBusinessAction(name deduct, commitMethod confirm, rollbackMethod cancel)void deduct(BusinessActionContextParameter(userId) String userId,BusinessActionContextParameter(money) int money);/**** 二阶段confirm确认方法、可以另命名但要保证与commitMethod一致** param context 上下文,可以传递try方法的参数* return boolean 执行是否成功 **/boolean confirm(BusinessActionContext context);/*** 二阶段回滚方法要保证与rollbackMethod一致* param context* return*/boolean cancel(BusinessActionContext context);
}2.导入冻结表
3.实现AccountTCCService接口
package cn.itcast.account.service.impl;import cn.itcast.account.entity.AccountFreeze;
import cn.itcast.account.mapper.AccountFreezeMapper;
import cn.itcast.account.mapper.AccountMapper;
import cn.itcast.account.service.AccountTCCService;
import io.seata.core.context.RootContext;
import io.seata.rm.tcc.api.BusinessActionContext;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;Service
Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {Autowiredprivate AccountMapper accountMapper;Autowiredprivate AccountFreezeMapper accountFreezeMapper;OverrideTransactionalpublic void deduct(String userId, int money) {//获取全局事务idString xid RootContext.getXID();AccountFreeze oldFreeze accountFreezeMapper.selectById(xid);if(oldFreeze ! null){return;}accountMapper.deduct(userId, money);//记录冻结的金额和事务AccountFreeze freeze new AccountFreeze();freeze.setUserId(userId);freeze.setFreezeMoney(money);freeze.setState(AccountFreeze.State.TRY);freeze.setXid(xid);accountFreezeMapper.insert(freeze);}Overridepublic boolean confirm(BusinessActionContext context) {String xid context.getXid();int count accountFreezeMapper.deleteById(xid);return count 1;}Overridepublic boolean cancel(BusinessActionContext context) {//查询冻结记录String xid context.getXid();String userId context.getActionContext(userId).toString();AccountFreeze freeze accountFreezeMapper.selectById(xid);//空回滚判断if (freeze null) {freeze new AccountFreeze();freeze.setUserId(userId);freeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);freeze.setXid(xid);accountFreezeMapper.insert(freeze);return true;}//幂等处理if(freeze.getState() AccountFreeze.State.CANCEL){return true;}//恢复可用余额accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());//将冻结的金额清零,状态改为CANCELfreeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);int count accountFreezeMapper.updateById(freeze);return count 1;}
}
需要注意的是:
1.空回滚判断需要在回滚业务中编写,且需要将记录插入到冻结表中,便于业务悬挂做出判断
2.对于业务悬挂需要先查询冻结表中是否有记录,如果有,一定是CANCEL执行过(因为对于没有回滚过的业务,在执行业务结束后对应的冻结表的字段一定为空,所以说有记录一定为CANCEL执行过),对于CANCEL执行过的事务说明全局事务已经完成,就必须拒绝此刻的try操作,否则会引起业务悬挂 5.Saga模式(了解)
Saga模式是SEATA提供的长事务解决方案。也分为两个阶段 一阶段直接提交本地事务 二阶段成功则什么都不做失败则通过编写补偿业务来回滚
Saga模式优点 事务参与者可以基于事件驱动实现异步调用吞吐高 一阶段直接提交事务无锁性能好 不用编写TCC中的三个阶段实现简单
缺点 软状态持续时间不确定时效性差 没有锁没有事务隔离会有脏写 四.四种模式对比 五.Seata高可用
什么是异地容灾?
确保在发生灾难性事件或紧急情况时组织的业务能够迅速恢复正常运行。异地容灾的主要目标是最小化业务中断并确保在灾难性事件后能够迅速恢复关键业务功能。
TC的异地多机房容灾架构
TC服务作为Seata的核心服务一定要保证高可用和异地容灾。 当一个地方的集群出现问题的时候,TC服务能快速切换到另外一个集群,故需要实现配置管理的热更新,就需要nacos配置管理来实现了,实现方式主要是在nacos统一配置管理,然后在各个微服务读取nacos中的properties文件即可(在每个微服务的yml文件指定nacos的地址和配置文件名称即可)
