怎么快速优化网站排名,个人网站怎么自己备案,解析网站接口怎么做,wordpress cron.sh本文主要是讲述分布式事务的理论及常用的技术方案#xff0c;主要源自各类学习和工作总结#xff0c;如有不妥之处#xff0c;还望指正。分布式事务的其他基础请自行查阅资料。
一、分布式事务产生的原因 分布式事务的产生#xff0c;源自互联网、电商等的发展#xff0c…本文主要是讲述分布式事务的理论及常用的技术方案主要源自各类学习和工作总结如有不妥之处还望指正。分布式事务的其他基础请自行查阅资料。
一、分布式事务产生的原因 分布式事务的产生源自互联网、电商等的发展当同一个系统不同模块不同业务的数据在一个存储设备里随着业务的发展系统逐渐满足不了业务的发展时常用的手段就是“拆”拆的手段有垂直拆分和水平拆分针对业务模块和数据库存储都可以进行垂直拆分和水平拆分。拆分后就会存在不同的业务使用自己的数据库进行存储这就会导致一个操作需要进行跨数据库操作。这就是分布式事务产生的最基本的原因所在。而我们知道只要是事务必须要满足事务的四性ACID为了使事务的四性得到满足业内使用了多种技术手段但各种技术手段都有其优点和缺点。
事务的四性ACIDAutomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性。
比如电商的下单里面包含写订单表、扣减商品库存、写财务结算订单信息、商品库存、财务模块按业务已经拆分到不同的模块各自有属于自己的数据库这个时候就是一个典型的分布式事务场景。
二、理论基础 此处主要说2个理论基础一个是分布式的CAP定理一个是BASE理论。
CAP指的是在一个分布式系统中一致性Consistency、可用性Availability、分区容错性Partition tolerance这三个要素最多只能同时实现两点不可能三者兼顾。在分布式场景中由于网络硬件等客观因素网络之间的通信可能会存在中断、丢包等情况所以分区容错性Partition tolerance是我们分布式场景中必须要满足的三要素中就只能有有这2种组合CP和AP。
APAP模型强调的是系统的可用性在做系统设计时需要优先考虑可用性
CPCP模型强调的是系统的一致性在做系统设计时需要优先考虑一致性
基于CAP定理的AP模型和CP模型又演化出了BASE理论。BASE是Basically Available基本可用、Soft state软状态和Eventually consistent最终一致性的简写。核心是既然没办法做到强一致性但每一个应用都可根据自身的业务特点采用适当的方式来达到最终一致性。
Basically Available基本可用指系统出现不可预知的故障时允许损失部分可用性但这绝不等价于不可用。比如系统某功能的正常响应时间是0.1秒但由于系统出现异常机房断电、光纤挖断等系统功能的响应时间升到1-2秒再比如电商的大促或秒杀为了保证系统的稳定性当用户流量超过了系统阈值可把部分用户引流到一个降级页面。
Soft state软状态与硬状态相对。系统中的数据存在中间状态并认为该中间状态不影响系统的整体可用性即表示数据副本之间的同步有延迟。
Eventually consistent最终一致性系统中的所有数据副本在经过一段时间后所有数据的状态都能达到一个最终的一致的状态。
三、刚性分布式事务 刚性分布式事务的特点是数据的状态强调的是强一致性系统能支持的并发低事务执行的时间都比较短属于短事务所有数据在事务内同步执行。刚性分布式事务遵循XA协议通过实现XA的接口来实现分布式事务。XA规范由APApplication Program、RMResource Manager、TMTransaction Manager组成。
AP定义事务的开始和结束并访问事务内的资源
RM通常指的就是数据库资源
TM负责管理事务分配事务的唯一标识、监控事务的执行情况、并负责事务的提交、回滚等操作
下面列出一些常见的实现XA协议的分布式事务方法。
两阶段提交2PC
也是XA的标准实现分为准备阶段和提交阶段时序图如下
AP向TM发起commit请求TM向RM发送prepare当TM收到所有的RM返回的ok消息后TM再向所有的RM发送commit指令待收到所有的RM返回的ok消息后commit才算完成。在prepare阶段当有一个RM返回失败的时候则不能进行第二步的commit操作TM释放所有占用的资源在commit阶段当有一个RM返回失败时则TM都要协调commit进行补偿保证所有提交到RM的commit请求要么都成功、要么都失败。
2PC的缺点
1、同步阻塞所有参与事务的资源都处于阻塞状态
2、TM瓶颈当TM故障时所有的参与者都将被锁定资源得不到释放
3、RM资源锁定时间过长
4、全局锁定隔离级别串行化不适合长事务并发低 基于2PC的缺点又提出三阶段3PC提交。
三阶段3PC提交
三阶段3PC提交分为CanCommit、PreCommit和DoCommit三个阶段时序图如下
CanCommitTM向所有RM发出CanCommit指令RM收到指令后判断可否提交事务如果可以返回ok否则返回no
PreCommit当TM收到所有RM都返回CanCommit的结果为ok时TM向所有RM发出PreCommit当有一个RM返回no或超时导致TM没收到反馈则事务中断TM向所有RM发出abort终止事务TM收到abort后终止事务释放资源。如果RM没收到TM发出的abort或是超时则RM也会中断自身的事务释放资源
DoCommitTM收到所有RM都返回PreCommit的结果为ok时TM向所有RM发出DoCommit执行事务真正的提交TM收到所有RM的DoCommit的执行结果为ok时释放所占用的所有资源当有一个RM返回no或超时导致TM没收到反馈则事务中断TM向所有RM发出abort终止事务各个RM收到abort后利用CanCommit阶段的Undo信息执行回滚操作释放占用的资源但是如果RM没收到TM发出的abort或是超时后则RM会继续提交事务这将导致数据的不一致。
三阶段相比两阶段优点有降低阻塞范围TM瓶颈问题得到部分解决即在第一二阶段时当超时的时候RM会自动释放资源不依赖TM。但进入第三阶段后如果超时则不会释放资源而会继续提交事务这种情况下将导致数据的不一致。
本篇到这结束下一篇继续解析柔性分布式事务。 ———————————————— 版权声明本文为CSDN博主「liaozxbj」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。 原文链接https://blog.csdn.net/liaozxbj/article/details/105436515
