网站每年要多少钱,快手广告联盟平台官网,手机网站字体自适应,广州公关公司有哪些持续学习持续更新中…
守破离 【雷丰阳-谷粒商城 】【分布式高级篇-微服务架构篇】【25】【分布式事务】 本地事务事务的基本性质事务的隔离级别#xff08;下面四个越往下#xff0c;隔离级 别越高#xff0c;并发能力越差#xff09;事务的传播行为#xff08;是否…
持续学习持续更新中…
守破离 【雷丰阳-谷粒商城 】【分布式高级篇-微服务架构篇】【25】【分布式事务】 本地事务事务的基本性质事务的隔离级别下面四个越往下隔离级 别越高并发能力越差事务的传播行为是否共用事务 事务的坑 本地事务方法互调其他方法的事务设置失效问题本地事务在分布式系统下只能控制住自己的回滚控制不了其他服务的回滚分布式事务分布式系统经常出现的异常CAP 定理分布式系统中实现一致性的 raft 算法BASE 理论强一致性、弱一致性、最终一致性 分布式事务几种方案2PC 模式柔性事务-TCC 事务补偿型方案柔性事务-最大努力通知型方案柔性事务-可靠消息最终一致性方案异步确保型 分布式事务—Seata整合Seata参考 本地事务
事务的基本性质
数据库事务的几个特性原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation) 和持久性(Durabilily)简称就是 ACID
原子性一系列的操作整体不可拆分要么同时成功要么同时失败一致性数据在事务的前后业务整体一致。转账。A:1000B:1000 转 200 事务成功 A800 B1200隔离性事务之间互相隔离。持久性一旦事务成功数据一定会落盘在数据库。
在以往的单体应用中我们多个业务操作使用同一条连接操作不同的数据表一旦有异常 我们可以很容易的整体回滚
Business我们具体的业务代码Storage库存业务代码扣库存Order订单业务代码保存订单Account账号业务代码减账户余额
比如买东西业务扣库存下订单账户扣款是一个整体必须同时成功或者失败一个事务开始代表以下的所有操作都在同一个连接里面
事务的隔离级别下面四个越往下隔离级 别越高并发能力越差 READ UNCOMMITTED读未提交 该隔离级别的事务会读到其它未提交事务的数据此现象也称之为脏读。 READ COMMITTED读已提交 一个事务可以读取另一个已提交的事务。Oracle和SQL Server的默认隔离级别。 同一个事务中该隔离级别下同样的 select 多次读取会读出不一样的结果此现象称为不可重复读问题 REPEATABLE READ可重复读 该隔离级别是 MySQL 默认的隔离级别 在同一个事务里同样的 select 操作select到的结果始终是事务开始时时间点的状态。 因此同样的 select 操作在该事务中读到的结果会是一致的但是会有幻读现象。MySQL 的 InnoDB 引 擎可以通过 next-key locks 机制来避免幻读。 SERIALIZABLE序列化 在该隔离级别下事务都是串行顺序执行的MySQL数据库的 InnoDB 引擎会给读操作隐式加一把读共享锁从而避免了脏读、不可重读复读和幻读问题。
事务的传播行为是否共用事务 PROPAGATION_REQUIRED如果当前没有事务就创建一个新事务如果当前存在事务 就加入该事务该设置是最常用的设置。 PROPAGATION_REQUIRES_NEW创建新事务无论当前存不存在事务都创建新事务。 PROPAGATION_SUPPORTS支持当前事务如果当前存在事务就加入该事务如果当前不存在事务就以非事务执行。 PROPAGATION_NOT_SUPPORTED以非事务方式执行操作如果当前存在事务就把当前事务挂起。 PROPAGATION_NEVER以非事务方式执行如果当前存在事务则抛出异常。 PROPAGATION_MANDATORY支持当前事务如果当前存在事务就加入该事务如果当前不存在事务就抛出异常。 PROPAGATION_NESTED如果当前存在事务则在嵌套事务内执行。如果当前没有事务则执行与 PROPAGATION_REQUIRED 类似的操作。
事务的坑 本地事务方法互调其他方法的事务设置失效
同一个对象内事务方法互调其他方法的事务设置默认失效原因绕过了代理对象没有用到代理对象事务使用代理对象来控制的解决使用代理对象来调用其他事务方法 1、引入aop-starterspring-boot-starter-aop引入了aspectjdependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-aop/artifactId/dependency2、EnableAspectJAutoProxy(exposeProxy true)开启 aspectj 动态代理功能。以后所有的动态代理都是aspectj创建的即使没有接口也可以创建动态代理。exposeProxy true对外暴露代理对象3、本类互调用代理对象调OrderServiceImpl orderService (OrderServiceImpl) AopContext.currentProxy();orderService.b();orderService.c();//事务的隔离级别(isolation Isolation.REPEATABLE_READ)//REQUIRED、REQUIRES_NEW//坑同一个对象内事务方法互调他们的事务设置默认失效原因事务使用代理对象来控制的直接调用绕过了代理对象Transactional(timeout 30)public void a() {//使用this调用bc做任何设置都没用。都是和a公用一个事务
// this.b(); 没用
// this.c(); 没用OrderServiceImpl orderService (OrderServiceImpl) AopContext.currentProxy();orderService.b(); //a事务。应用到了自己的事务设置REQUIRED如果是REQUIRED那么自己的事务设置不起作用和a()共用orderService.c(); //新事务。应用到了自己的事务设置REQUIRES_NEW, timeout 20 自己的事务设置起作用
// bService.b(); //a事务
// cService.c(); //新事务int i 10 / 0;}Transactional(propagation Propagation.REQUIRED, timeout 2)public void b() {//执行了7s回滚不}Transactional(propagation Propagation.REQUIRES_NEW, timeout 20)public void c() {}问题本地事务在分布式系统下只能控制住自己的回滚控制不了其他服务的回滚 库存调用成功了但是网络原因或者其他原因导致Feign调用超时了此时订单回滚库存不会回滚。假如还有个远程扣减积分服务是在订单服务调用成功后调用的该服务出异常 订单会回滚由于库存服务已经成功的远程执行不会回滚。 //本地事务在分布式系统下只能控制住自己的回滚控制不了其他服务的回滚//应该使用分布式事务但是分布式事务比较复杂比较复杂的最大原因网络问题分布式机器。
// GlobalTransactional //高并发TransactionalOverridepublic SubmitOrderResponseVo submitOrder(OrderSubmitVo vo) {confirmVoThreadLocal.set(vo);SubmitOrderResponseVo response new SubmitOrderResponseVo();MemberRespVo memberRespVo LoginUserInterceptor.loginUser.get();response.setCode(0);String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end;String orderToken vo.getOrderToken();Long result redisTemplate.execute(new DefaultRedisScriptLong(script, Long.class), Arrays.asList(OrderConstant.USER_ORDER_TOKEN_PREFIX memberRespVo.getId()), orderToken);if (result 0L) {response.setCode(1);return response;} else {//令牌验证成功 //下单去创建订单验令牌验价格锁库存...//1、创建订单订单项等信息OrderCreateTo order createOrder();//2、验价if (Math.abs(order.getOrder().getPayAmount().subtract(vo.getPayPrice()).doubleValue()) 0.01) { //金额对比// 3、保存订单saveOrder(order);//4、库存锁定。只要有异常回滚订单数据。// 库存锁定需要的数据订单号所有订单项skuIdskuNamenum//4、远程锁库存R r wareFeignService.orderLockStock(getLockVo(order));//TODO 问题1库存调用成功了但是网络原因或者其他原因导致Feign调用超时了此时订单回滚库存不会回滚。if (r.getCode() 0) {//锁成功了response.setOrder(order.getOrder());//TODO 问题2假如还有个远程扣减积分服务// 该服务出异常 订单会回滚由于库存服务已经成功的远程执行不会回滚。int i 10/0; //模拟扣减积分出异常//TODO 清除购物车已经下单的商品return response;} else {//锁定失败response.setCode(3);String msg (String) r.get(msg);throw new NoStockException(msg);}} else {response.setCode(2);return response;}}}分布式事务
分布式系统经常出现的异常
机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP、存储数据丢失… 分布式事务是企业集成中的一个技术难点也是每一个分布式系统架构中都会涉及到的一个东西特别是在微服务架构中几乎可以说是无法避免。
CAP 定理
CAP 原则又称 CAP 定理指的是在一个分布式系统中
一致性Consistency在分布式系统中的所有数据备份在同一时刻是否同样的值。等同于所有节点访 问同一份最新的数据副本可用性Availability在集群中一部分节点故障后集群整体是否还能响应客户端的读写请求。对数据 更新具备高可用性分区容错性Partition tolerance大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区partition。 分区容错的意思是区间通信可能失败。比如一台服务器放在中国另一台服务器放在美国这就是两个区它们之间可能无法通信。
CAP 原则指的是这三个要素最多只能同时实现两点不可能三者兼顾。 一般来说分区容错无法避免因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们 剩下的 C 和 A 无法同时做到。
对于多数大型互联网应用的场景主机众多、部署分散而且现在的集群规模越来越大所 以节点故障、网络故障是常态而且要保证服务可用性达到 99.99999%N 个 9即保证 P 和 A舍弃 C。
分布式系统中实现一致性的 raft 算法
http://thesecretlivesofdata.com/raft/
https://raft.github.io/
raft算法核心领导选举、日志复制
领导选举、日志复制这两个动作的过程中有两个时间在起作用自旋时间 随机的也叫选举时间、心跳时间固定的指定的时间间隔
raft算法下的节点有三个状态随从、候选者 、领导
领导根据心跳时间给随从发送心跳可能会附加日志通过日志可以更新其他节点的数据随从收到消息会回复领导 并将随从自己的自旋时间重置随从如果接收不到领导者的消息会在随机自旋时间结束后成为候选者候选者会让其他节点为自己投票选自己成为新一轮的领导加上自己大多数同意即可
raft算法下对系统的所有更改都要经过领导者
Raft 可以在面对网络分区时保持一致。
BASE 理论
BASE 理论是对 CAP 理论的延伸思想是即使无法做到强一致性CAP 的一致性就是强一致性但可以采用适当的弱一致性即最终一致性。
BASE 是指 基本可用Basically Available 基本可用是指分布式系统在出现故障的时候允许损失部分可用性例如响应时间、 功能上的可用性允许损失部分可用性。需要注意的是基本可用绝不等价于系 统不可用。响应时间上的损失正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的 查询结果但由于出现故障比如系统部分机房发生断电或断网故障我 们就得去查其他节点导致查询 结果的响应时间增加到了 1~2 秒。功能上的损失购物网站在购物高峰如双十一时为了保护系统的稳定性 部分消费者可能会被引导到一个降级页面。 软状态 Soft State 软状态是指允许系统存在中间状态成功状态、中间状态、失败状态而该中间状态不会影响系统整体可用性。分布 式存储中一般一份数据会有多个副本允许不同副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。 最终一致性 Eventual Consistency 最终一致性是指系统中的所有数据副本经过一定时间后最终能够达到一致的状态。弱一致性和强一致性相反最终一致性是弱一致性的一种特殊情况。
强一致性、弱一致性、最终一致性
从客户端角度多进程并发访问时更新过的数据在不同进程如何获取的不同策略决定了不同的一致性。
对于关系型数据库要求更新过的数据能被后续的访问都能看到这是强一致性。
如果能容忍后续的部分或者全部访问不到则是弱一致性。
如果经过一段时间后要求 能访问到更新后的数据则是最终一致性
分布式事务几种方案
2PC 模式
数据库支持的 2PC【2 phase commit 二阶提交】又叫做 XA Transactions。
MySQL 从 5.5 版本开始支持SQL Server 2005 开始支持Oracle 7 开始支持。
其中XA 是一个两阶段提交协议该协议分为以下两个阶段
第一阶段事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作并反映是 否可以提交.第二阶段事务协调器要求每个数据库提交数据。
其中如果有任何一个数据库否决此次提交那么所有数据库都会被要求回滚它们在此事务 中的那部分信息。 XA的特点 刚性事务 XA 协议比较简单而且一旦商业数据库实现了 XA 协议使用分布式事务的成本也比较 低。 XA 性能不理想特别是在交易下单链路往往并发量很高XA 无法满足高并发场景 XA 目前在商业数据库支持的比较理想在 mysql 数据库中支持的不太理想mysql 的 XA 实现没有记录 prepare 阶段日志主备切换回导致主库与备库数据不一致。 许多 nosql 也没有支持 XA这让 XA 的应用场景变得非常狭隘。 也有 3PC引入了超时机制无论协调者还是参与者在向对方发送请求后若长时间 未收到回应则做出相应处理
柔性事务-TCC 事务补偿型方案
刚性事务遵循 ACID 原则强一致性。柔性事务遵循 BASE 理论最终一致性
与刚性事务不同柔性事务允许一定时间内不同节点的数据不一致但要求最终一致。 一段业务代码分为三个方法 try(prepare)、confirm(commit)、 cancel(rollback)
一阶段 prepare 行为调用 自定义 的 prepare 逻辑。二阶段 commit 行为调用 自定义 的 commit 逻辑。二阶段 rollback 行为调用 自定义 的 rollback 逻辑。
所谓 TCC 模式是指支持把 自定义 的分支事务纳入到全局事务的管理中。 柔性事务-最大努力通知型方案
按规律进行通知不保证数据一定能通知成功但会提供可查询操作接口进行核对。
这种 方案主要用在与第三方系统通讯时比如调用微信或支付宝支付后的支付结果通知。
这种 方案也是结合 MQ 进行实现例如通过 MQ 发送 http 请求设置最大通知次数。达到通 知次数后即不再通知。
案例银行通知、商户通知等各大交易业务平台间的商户通知多次通知、查询校对、对 账文件支付宝的支付成功异步回调
柔性事务-可靠消息最终一致性方案异步确保型
发送端防止消息丢失
做好消息确认机制publisherconsumer【手动ack】每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一遍
消费者
开启手动ACK将消费者的业务消费接口设计为幂等的比如要解锁库存先判断状态
分布式事务—Seata
https://seata.apache.org/zh-cn/docs/overview/terminology/ TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器定义全局事务的范围开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器管理分支事务处理的资源与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。
整合Seata
https://seata.apache.org/zh-cn/docs/user/quickstart/
每一个微服务先必须创建 undo_log 表
CREATE TABLE IF NOT EXISTS undo_log
(branch_id BIGINT NOT NULL COMMENT branch transaction id,xid VARCHAR(128) NOT NULL COMMENT global transaction id,context VARCHAR(128) NOT NULL COMMENT undo_log context,such as serialization,rollback_info LONGBLOB NOT NULL COMMENT rollback info,log_status INT(11) NOT NULL COMMENT 0:normal status,1:defense status,log_created DATETIME(6) NOT NULL COMMENT create datetime,log_modified DATETIME(6) NOT NULL COMMENT modify datetime,UNIQUE KEY ux_undo_log (xid, branch_id)) ENGINE InnoDB AUTO_INCREMENT 1 DEFAULT CHARSET utf8mb4 COMMENT AT transaction mode undo table;
ALTER TABLE undo_log ADD INDEX ix_log_created (log_created);导入依赖 spring-cloud-starter-alibaba-seata dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-seata/artifactId/dependency安装事务协调器seata-serverseata-all-0.7.1所以该项目使用seata-server-0.7.1.zip https://github.com/seata/seata/releases
解压seata-server修改注册中心配置registry.conf并启动seata-server registry {type nacosnacos {serverAddr localhost:8848...}}所有想要用到分布式事务的微服务使用seata的DataSourceProxy代理自己的数据源
Configuration
public class MySeataConfig {AutowiredDataSourceProperties dataSourceProperties;Beanpublic DataSource dataSource(DataSourceProperties dataSourceProperties){HikariDataSource dataSource dataSourceProperties.initializeDataSourceBuilder().type(HikariDataSource.class).build();if (StringUtils.hasText(dataSourceProperties.getName())) {dataSource.setPoolName(dataSourceProperties.getName());}return new DataSourceProxy(dataSource);}}每个微服务都必须把seata-server-0.7.1/conf目录下的registry.conf、file.conf这两个文件拷贝到自己的resources目录下然后修改自己微服务下的file.conf
vgroup_mapping.{application.name}-fescar-service-group default
比如订单服务
vgroup_mapping.gulimall-order-fescar-service-group default给分布式大事务的入口标注GlobalTransactional,每一个远程的小事务用Transactional GlobalTransactional
// TransactionalOverridepublic SubmitOrderResponseVo submitOrder(OrderSubmitVo vo) {//1、创建订单订单项等信息OrderCreateTo order createOrder();// 3、保存订单saveOrder(order);//4、库存锁定。只要有异常回滚订单数据。// 库存锁定需要的数据订单号所有订单项skuIdskuNamenum//4、远程锁库存R r wareFeignService.orderLockStock(getLockVo(order));//TODO 问题1库存调用成功了但是网络原因或者其他原因导致Feign调用超时了此时订单回滚库存不会回滚。if (r.getCode() 0) {//锁成功了response.setOrder(order.getOrder());//TODO 问题2假如还有个远程扣减积分服务// 该服务出异常 订单会回滚由于库存服务已经成功的远程执行不会回滚。int i 10/0; //模拟扣减积分出异常} }/*** 为某个订单锁定库存** Transactional(rollbackFor NoStockException.class)* 默认只要是运行时异常都会回滚*/TransactionalOverridepublic Boolean orderLockStock(WareSkuLockVo vo) {//TODO 按照下单的收货地址找到一个就近仓库锁定库存。//1、找到每个商品在哪个仓库都有库存ListOrderItemVo locks vo.getLocks();启动测试分布式事务
参考
雷丰阳: Java项目《谷粒商城》Java架构师 | 微服务 | 大型电商项目. 本文完感谢您的关注支持
