网站后台上图片后网页显示不正确,广西建设网站网址多少,软件开发公司排名国内,网站怎样免费推广微服务数据一致-事务与分布式事务
概述
事务是计算机科学和数据库管理中的一个关键概念#xff0c;用于确保数据的一致性和可靠想。事务管理是大多数应用程序和数据库系统中不可或缺的一部分。分布式事务扩展了事务的概念#xff0c;用于多个分布式系统和服务的数据一致性管…微服务·数据一致-事务与分布式事务
概述
事务是计算机科学和数据库管理中的一个关键概念用于确保数据的一致性和可靠想。事务管理是大多数应用程序和数据库系统中不可或缺的一部分。分布式事务扩展了事务的概念用于多个分布式系统和服务的数据一致性管理。本调查报告将深入探讨事务和分布式事务的概念、特性、类型和应用以及事务处理的最佳时间
事务
什么事事务
事务是一组数据库操作的逻辑单元要么全部成功执行要么全部失败回滚以保证数据的一致性和完整性。事务遵循ACID属性即原子性Atomicity、一致性Consistency隔离性Isolation和持久性Durability。
ACID属性
原子性Atomicity事务中的所有操作要么全部成功要么全部失败。如果发生故障或异常事务应该会滚到起始状态。一致性Consistency事务将数据从一个一致状态转移到另一个一致状态。在事务结束后所有约束和规则都应得到满足隔离性Isolation事务应该在隔离的环境中执行即使多个事务并发执行也不相互干扰。数据库管理系统提供不同级别的隔离度。持久性Durability一旦事务提交其结果应该用具保存在数据库中技术发生故障也不会丢失
如何保证原子性
innodb利用undo log实现原子性。undo log名为回滚日志是实现原子性的关键当事务回滚是能够撤销虽有已经执行成功的sql语句它需要记录你要回滚的相应的日志信息。比如delete一个数据的时候就需要记录这条数据的信息回滚的时候insert这条旧数据。当事务执行功能失败或调用rallback导致事务需要回滚便可以利用undo log中的信息将数据回滚到修改之前的样子。
如何保证持久性
在修改数据的时候Mysql先把磁盘上的数据加载到内存中在内存中对数据修改再刷到磁盘中。如果在刷盘前宕机内存中的数据就会丢失。
解决思路事务提交前直接把数据写入磁盘中。 引入问题性能损耗严重只修改一个页16k里面的一个字节就需要把整个页面刷入磁盘。另外一个事务的SQL可能涉及到多个数据页的修改存在随机IO的可能速度会更慢。解决思路使用redo log 修改数据的时候不仅内存中操作还会在redo log中记录这次操作当事务提交的时候会将redo log日志进行刷盘。当数据库宕机重启的时候会将redo log中的内容恢复到数据库中再根据undo log和binlog内容决定回滚数据还是提交数据。
一条数据的更新流程 事务并发带来的问题及隔离级别
当事务并发的时候会带来一下问题
脏读一个事务访问到另一个事务未提交的数据。不可重复读一个事务多次读取同一个数据的过程中数值发生变化。幻读一个事务多次读取同一个数据的过程中, 全局数据(表的结构)发生了改变。
为了解决并发事务带来的问题提供了事务的隔离级别
读未提交允许读取未提交的内容这种级别下查询不会加锁存在脏读、幻读、不可重复的问题。读已提交只允许读取已提交的内容但是仍然会存在幻读、不可重复度的问题。可重复读用行级锁来保证一个事务在相同查询条件下两次查询结果一致 , 可以避免脏读, 不可重复读, 但无法避免幻读。Innodb解决了幻读问题串行化用表级锁来保证所有事务串行化, 可以防止所有的异常情况, 但牺牲了数据库的并发性。
事务隔离级别实现的原理
读未提交 事务对当前读的数据不加锁都是当前读。事务在更新数据的瞬间必须先对其加行级共享锁直到事务结束才释放。 读已提交 事务对当前读的数据不加锁是快照读。事务在更新数据的瞬间必须先对其加行级排他锁record直到事务结束才释放。 可重复读 事务对当前读的数据不加锁且是快照读。事务在更新数据的瞬间必须对其加行级排他锁record、gap、nest-key直到事务结束才释放 串行化 事务在读数据时必须先对其加表级共享锁直到数据结束才释放都是当前读。事务在更新数据是必须先对其加表级排他锁直到事务结束才释放。
Spring中的事务管理
事务的传播行为
PROPAGATION_REQUIRED默认的事务事务传播行为如果存在当前事务则加入当前事务如果不存在则创建一个新的。 如果外部方法没有开启事务PROPAGATION_REQUIRED修饰的内部方法会开启自己的事务且开启的事务相互独立互不干扰。如果外部方法开启了事务且是PROPAGATION_REQUIRED则外部和内部方法属于一个事务只要一个方法回滚整个事务都需要回滚即A外部方法影响B内部方法B影响A。 PROPAGATION_REQUIRED_NEW创建一个新的事务如果当前存在事务则把当前事务挂起。 不管外部方法是否开启事务PROPAGATION_REQUIRED_NEW修饰的方法都会开启自己的事务。外部方法的事务与内部方法的事务相互独立互不干扰。即A不影响BB不影响A。 PROPAGATION_SUPPORTS如果当前存在事务则加入该事务否则以非事务方式运行。PROPAGATION_NOT_SUPPORTS以非事务方式运行如果当前存在事务则把当前事务挂起。PROPAGATION_MANDATORY如果当前存在事务则加入该事务如果当前没有事务则抛出异常。PROPAGATION_NEVER以非事务方式运行如果当前存在事务则抛出异常。PROPAGATION_NESTED如果当前存在事务就在当前事务内执行。否则就执行与PROPAGATION_REQUIRED类似的操作 A影响BB不影响A。
事务失效的几种情况
抛出事务不支持的异常 Spring事务默认支持RuntimeException如果抛出的异常为RuntimeException及其子类异常事务均可生效。如果是抛出的Exception异常则失效。解决方案指定Spring事务异常捕获类型Transactional(rollbackFor Exception.class)或抛出spring事务支持的异常类型。使用了try-catch 异常被try-catch捕获导致事务失效。解决方案在catch中抛出Spring事务支持的异常。事务方法为私有方法 Spring声明式事务是基于动态代理实现的private方法不能被代理事务不生效。此外static方法属于类不属于任何对象也不会被代理事务不生效。final方法无法被重写也不能被代理事务不生效。未被Spring管理的类 Spring实现对象的动态代理首先这个对象要交给Spring管理一个方法调用本类的另一个方法 Transactional基于AOP实现而AOP又是基于动态代理实现直接调用本类方法或使用this调用本类方法均不是Spring的代理对象无法实现动态代理事务也就不会生效。数据表不支持事务Spring事务传播级别设置为不支持事务
分布式事务
什么是分布式事务
分布式事务是在分布式系统中维护数据一致性的方式。它扩展了ACID事务的概念以跨越多个分布式服务、数据库和资源的范围来保证数据的一致性。
分布式事务面临的挑战
网络延迟跨网络执行事务可能导致较高的延迟影响性能。故障处理分布式系统中的节点故障可能导致事务的不一致状态需要复杂的故障处理机制。并发控制多个事务同时访问和修改共享数据需要有效的并发控制机制。
分布式事务的历史与发展
分布式事务的历史和发展经历了多个阶段从早期的两阶段提交到最近的新兴分布式数据库和NoSQL解决发方案。
两阶段提交2PC 1980年代末到1990年代初提出了两阶段提交。两阶段提交通过协调者和参与者的协作确保在多个分布式数据库之间的事务具有原子性和一致性。2PC的问题在于它可能导致性能瓶颈和阻塞因为在第二阶段需要等待所有参与者的确认。 三阶段提交3PC 为了阶段2PC的一些问题提出了三阶段提交。3PC引入了一个预提交节点以减少阻塞问题然而它仍然存在某些情况下无法解决的问题。 XA事务 XAeXtended Architecture是一种用于分布式事务的标准由X/Open组织制定。XA事务使用了分布式管理器TransactionManager来协调多个资源管理器Resource Manager的事务。XA事务提供了分布式事务的一些标准化机制但它在性能可伸缩性方面仍然有限制 Sage模式 Sage是一种分布式事务模型将长事务拆分成一系列小事务并使用补偿事务来处理部分失败。Sage模式在微服务架构中得到广泛应用以提高系统的可伸缩性和可恢复性。 NoSQL数据库 随着分布式计算和大数据的兴起出现了各种新兴的NoSQL数据库如Cassandra、MongoDB和Couchbase。这些数据库通过采用了最终一致性的模型提高性能和可用性。NoSQL数据库的出现使得开发人员需要重新考虑分布式事务的模型并引用了新的解决方案如CRDTsConfict-Free Replicated Data Types。 新兴分布式数据库 近年来出现了一些性能的分布式数据库系统如Google的Spanner和CockroachDB它们旨在提供全球分布式事务的支持。这些系统使用全球分布式的时间同步和意义性协议来实现强一致性的分布式事务。 区块链技术 区块链技术引入了一种分布式账本的概念其中的交易具有强一致性和不可变性。这使得区块称为一种分布式事务的潜在选择尤其是金融和合同领域。
分布式事务处理方法
2PC
两阶段提交是一种强一致性设计它引入一个事务协调者的角色协调管理各个参与者的提交和回滚。
准备阶段Phase1 - Prepare Phase 协调者向所有参与者发送事务准备请求参与者收到请求后会执行事务的准备操作并准备好事务的状态提交或回滚保存到本地参与者在准备完成后向协调者发送准备完成的通知同时将本地准备状态持久化 提交阶段Phase2 - Commit Phase 协调者在收到所有参与者的准备完成通知后如果所有参与者都准备就绪将向所有参与者发送事务提交请求。参与者接受到提交请求后会执行事务的提交操作将事务永久性的应用到系统中并释放之前的资源。参与者在完成提交后发送提交完成的通知。 回滚阶段Phase2 - Rollback Phase 如果在准备阶段任何参与者没有准备好或者有参与者在提交阶段失败协调者将会向所有参与者发送事务回滚请求。参与者接受到回滚请求后会执行事务回滚操纵将之前的操作撤销并释放资源。参与者在完成回滚后向协调者发送回滚完成的通知。
2PC存在的问题
同步阻塞所有的参数者都是事务同步阻塞型的当参与者占有公共资源时其他三方访问公共资源不得不处于阻塞状态。单点故障一旦协调者发生故障系统不可用。数据不一致当协调者发送commit之后有的参与者收到commit消息事务执行成功有的没有收到处于阻塞状态这段时间会产生数据不一致情况。不确定性当协调者发送commit后并且此时只有一个参与者收到commit那么当该参与者与协调器同时宕机后重新选举的协调者无法确定该消失是否提交成功。
2PC的优势在于对业务没有侵入可以利用数据库自身机制急性事务的提交和回滚。常见的机遇2PC的具体落地方案有JTAXA规范和SeataAT模式
3PC
三阶段提交是二阶段提交的改进版本在协调者和参与者都引入了超时机制在2PC中的准备阶段和提交阶段增加了一个预提交阶段。
准备阶段CanCommit协调者向各个参与者发送请求询问是否可以执行事务但并不是执行事务。预提交阶段PreCommit如果从协调者得到反馈是满足执行条件那么就发送预提交请求并开始执行事务如果从协调者得到返回时不满足执行条件或者超时则发送事务中断请求。提交阶段DoCommit如果预提交阶段发送的是预提交请求那么正常提交事务如果预提交阶段发送的是事务中断请求那么直接中断事务。 相对于 2PC3PC 主要解决的单点故障问题并减少阻塞因为一旦参与者无法及时收到来自协调者的信息之后他会默认执行 commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题因为由于网络原因协调者发送的中断响应没有及时被参与者接收到那么参与者在等待超时之后执行了 commit 操作。这样就和其他接到中断命令并执行回滚的参与者之间存在数据不一致的情况。而且 3PC 整体的交互过程更长性能也会有所下降。 3PC 目前似乎只存在于理论还没有具体落地方案。
TCC
2PC和3PC都是依赖于数据库的事务提交和回滚但是有时候很多业务并不知涉及到数据库可能会发送短信、消息等而TCC就是属于业务层面的分布式应用。 TCC方案分为Try-Confirm-Cancel三个阶段属于补偿性分布式事务。
Try阶段完成所有业务检查一致性预留业务资源隔离性Confirm阶段确认执行业务操作不再做任何业务检查只使用Try阶段预留的业务资源。Cancel阶段取消Try阶段预留的业务资源。 Try阶段失败了会执行CancelConfirm阶段失败会不断进行重试或者进行人工干预。 TCC需要根据每个场景和业务逻辑来设计相应的操作所以很大程度增加了业务代码的复杂度对业务有很大的侵入。但是没有资源阻塞每一个方法都是直接提交事务的如果出错是通过业务层面的Cancel来进行补偿所以也称补偿事务方法。
TCC要注意的几个问题
幂等问题因为网络调用无法保证请求一定能到达所以都会有重试机制因此对于Try、Confirm、Cancel三个方法都需要幂等实现避免重复执行产生错误。空回滚问题指的是Try方法由于网络问题没有收到超时了此时事务管理器就会发出Cancel命令那么需要支持Cancel在没有执行Try的情况下能正常Cancel。悬挂问题这个问题也是指Try方法由于网络阻塞超时出发了事务管理器发出了Cannel命令但是执行了Cancel命令之后Try请求到了。所以空回滚之后还得记录一下防止Try的再调用。
可靠消息最终一致性方案
RocketMQ4.3之后的版本正式支持事务消息。
服务A生产者向Broker消息中间件发送一个HalfMessage半消息消息发送到Broker端但是消息的状态被标记为“不能投递”即消费者看不到半消息发送成功后服务A执行本地事务。事务执行成功向Broker发送Commit命令此时半消息就变成了可以被消费的消息如果失败则发送一个RollBack命令该消息会被删除。服务B消费者收到消息后消费该消息即可。在RocketMQ没有收到服务A确认状态的消息那么半消息会自宋定时轮询毁掉接口询问这个处理的处理情况。服务B在执行的过程中也可能会失败这时需要重试一直执行不成功也需要人工介入同时也需要保证服务B方法的幂等性。
应用场景
分布式事务适用于需要数据一致性的多个应用场景包括
电子商务确保订单处理、支付和库存管理等操作的一致性。金融服务跨银行交易、交易清算和资金阶段的一致性管理。物流和供应链跨多个仓库、配送中心和供应商的库存和订单管理。在线游戏多玩家游戏中的虚拟经济和资源管理。
结论
事务和分布式事务是分布式系统和数据库管理中的关键概念了解了它们的原则、属性和实现方式对于构建高可用、高性能和数据一致性的应用程序至关重要。在选择分布式事务方案是需要根据应用的的要求权衡性能、复杂度和一致性。
引用
https://www.cnblogs.com/chengxy-nds/p/14046856.html
