五寨网站建设,苏州专业网站建设定制,做建材网站,网站首页模板图片数据库事务
Atomicity 原子性 某个操作#xff0c;要么全部执行完毕#xff0c;要么全部回滚
Consistency 一致性 数据库中的数据全都符合现实世界的约束#xff0c;则这些数据就符合一致性。 比如性别约束男or女#xff0c;人名币面值不能为负数#xff1b;出生地址不能…数据库事务
Atomicity 原子性 某个操作要么全部执行完毕要么全部回滚
Consistency 一致性 数据库中的数据全都符合现实世界的约束则这些数据就符合一致性。 比如性别约束男or女人名币面值不能为负数出生地址不能为null参与转账的账户总余额不变等等。
Isolation 隔离性 多个事务访问相同数据时对该数据不同状态的转换对应的数据库操作的执行顺序有一定的规律彼此不干涉
Burability 持久性 现实中的状态转换映射到数据库中意味着对数据所做的修改都应该在磁盘中保存
事务的状态有哪些 事务并发执行时数据一致性问题有哪些
脏读 如果一个事务提取到了另一个未提交事务小丽修改过的数据。就意味着发生了脏读现象
不可重复读 如果一个事务修改了另一个未提交事务读取的数据就意味着发生了不可重复读现象或者叫模糊读FuzzyRead 幻读 如果一个事务先根据某些搜索条件(select … where vip‘是’)查询到了一些记录但是在该事务并未提交时另一个事务小丽写入了一些符合上面搜索条件的记录这里的写入可以值insert、delete、update操作。例如insert into … values(‘0003’,700,‘是’)就意味着发生了幻读现象。
SQL事务隔离级别
无论哪种隔离级别都不允许脏写的情况发生所以没有列入表格内
分布式场景下事务及数据一致性问题
在系统开发过程中我们据大部分时间使用的是关系型数据库那么当数据量不大的时候我们通过单库单表就可以保证某个业务数据的存储能力了并且通过数据库对事务的支持可以很好的解决数据一致性问题。
但是当数据量增大了之后不仅仅是单表查询效率Bianca低下而且数据所占用空间的限制都会促使着我们采用分库分表的解决方案。但是当涉及到分库的时候却打破了我们依赖数据库控制事务一致性的便捷方式只能物品们采用其他方案来进行事务的控制因此分布式场景下数据一致性问题就显著的凸显了出来。
既然谈到分库我们来看一下常见的两种分库方式即水平分库和垂直分库。
水平分库 当公司在创业初期业务刚刚起步我们的订单表每天能产生5W条数据那么放到一张表中完全可以应对现在的业务需求。
但是随着公司的发展业务逐一的在推进订单量一年后突增为100W那为了应对公司业务的发展和高速增长的订单量就会将数据库扩展为A,B,C这三个库并且在每个数据库中按照相同的表结构复制出多份来平均分摊每天产生的订单。那么这种分库的方式就是水平分库。 垂直分库 随着公司发展我们都无法避免要从创业初期的单体架构拆分成微服务架构那么针对不同的业务域会进行服务的拆分那么面对着代码曾念的解耦解决了之后面对数据库层面的解耦如何处理呢
那么很容易我们就会想到要将A库按照不同的业务域进行拆分比如拆分成订单库删评库存库支付库等等。那么面对着这种数据库的拆分方式就是垂直分库了如下图所示 分布式事务解决方案
分布式服务购物逻辑伪代码实现 我们以快捷支付的方式在商城购买商品为例即下完订单自动支付看一下分布式事务在实现上与非分布式的区别。前提是我们针对订单服务、库存服务和支付服务这三个服务都有对应的三个数据库分别是订单库、库存库和支付库。
如果我们平时以声明式事务来编码那么他与本地事务在编码上没有区别都是标注一个Transaction注解而已但是如果以编程式事务来实现的话就能在写法上看出差异了伪代码如下所示 由于订单库存和支付是三个服务和数据库所以我们需要分别开启这三个数据库事务并且执行完毕后分别执行三次commit操作
如果在调用payTransaction.commit()方法时出现了异常那么由于order和stock已经成功的调用了commit所以无法执行rollback操作了。而只有pay服务可以正常回滚。那么就造成了分布式事务的不一致性。
分布式事务解决方案概述 刚性事务强一致性事务 XA 2PC 3PC 柔性事务 可靠时间队列 TCC SAGA 基于数据补偿
刚性事务 - XA 为了解决分布式事务一致性问题X/Open组织提出了一套名为X/Open XA的处理事务架构其核心内容是定义了全局的事务管理器和局部的资源管理器之间的通信接口。XA接口是双向的能在一个事务管理器和多个资源管理器之前形成通信桥梁通过协调多个数据源的一致动作实现全局事务的统一提交或者统一回滚。
XA并不是Java的技术规范二十一套跟语言无关的通用规范所以Java中专门定义了JSR 907 Java Transaction API 基于XA模式在Java语言中实现了全局事务处理的标准这也就是我们现在熟知的JTA。
JTA最主要的两个接口如下
事务管理器接口满足XA规范的资源定义接口
刚性事务(2PC) 为了保证整个事务的一致性XA将事务提交拆分成两阶段即二段式提交协议交互时序示意图如下所示 刚性事务(3PC) 为了缓解2PC中协调者的单点问题和准备阶段的性能问题后续发展出了“三段式提交”即 3PC协议交互时序示意图如下所示
柔性事务(可靠事务队列)
以快捷支付为例当用户下单的时候自动就进行了支付扣款操作。那么创建订单、扣减库存和支付扣款这三个操作就应该是一个原子性的操作。那么如果我们采取可靠时间队列的方式则流程如下图所示 柔性事务(TCC) TCC 是 Try-Confirm-Cancel的缩写是常见的分布式事务机制
在具体实现上TCC较为繁琐他是一种业务侵入式较强的事务方案要求业务处理过程必须拆分成“预留业务资源”和“确认/释放消费资源”两个子过程。 Try尝试执行阶段) 完成所有业务可执行性的检查保障一致性并且预留好全部需要用到的业务资源保障隔离性。
Confirm(确认执行阶段 不进行任何业务检查直接使用Try阶段准备的资源来完成业务处理。 Confirm阶段可能会重复执行因此本阶段执行的操作需要具备幂等性。
Cancel取消执行阶段 释放Try阶段预留的业务资源 Cancel阶段可能会重复执行因此本阶段执行的操作需要具备幂等性。
柔性事务SAGA SAGA事务把一个大事务分解为可以交错运行的一系列子事务集合。原本SAGA的目的是避免大事务长时间锁定数据库资源后来才发展成将一个分布式环境中的大事务分解成一系列本地事务的设计模式。
与TCC相比SAGA不需要为资源设计冻结状态和撤销冻结的操作补偿操作往往要比冻结操作容易实现的多。
SAGA必须保证所有子事务都得以提交或者补偿但SAGA系统本身也有可能会崩溃所以他必须设计成与数据库类似的日志机制被称为SAGA log)以保证系统恢复后可以追踪到子事务的执行情况比如执行到哪一步或者补偿到哪一步了。 - 柔性事务基于数据补偿
Seata的AT模式就是基于数据补偿来代替回滚思路的
AT事务是参照了XA两段提交协议实现的但是AT并不需要等待所有数据源都返回成功采取执行全局提交而是通过了拦截SQL的方式生成前后镜像生成行锁通过本地事务一起提交到操作的数据源中相当于自己记录了重做和回滚日志。
如果分布式事务成功提交那后续清理每个数据源中对应的日志数据即可如果分布式事务需要回滚就根据日志数据自动产生同用于补偿的逆向SQL“。
刚性事务和柔性事务对比 一致性保障XA TCC SAGA 事务消息 业务友好性XA 事务消息 SAGA TCC 性能损耗XA TCC SAGA 事务消息
