免费做链接的网站,广东品牌网站建设平台,wordpress mip模板,企业网站建设合作协议范文文章目录 分布式事务#xff1a;1、一致性理论2、两阶段提交#xff08;2PC#xff09;3、三阶段提交#xff08;3PC#xff09;4、Seata分布式事务方案 上一篇降到了
分布式锁#xff0c;先来和大家聊一聊分布式事务#xff0c; 分布式锁的链接如下#xff1a;
http… 文章目录 分布式事务1、一致性理论2、两阶段提交2PC3、三阶段提交3PC4、Seata分布式事务方案 上一篇降到了
分布式锁先来和大家聊一聊分布式事务 分布式锁的链接如下
https://blog.csdn.net/weixin_44797327/article/details/134611193?spm1001.2014.3001.5502 分布式事务
1、一致性理论 分布式事务的目的是保障分库数据一致性而跨库事务会遇到各种不可控制的问题如个别节点永久性宕机像单机事务一样的ACID是无法奢望的。另外业界著名的CAP理论也告诉我们对分布式系统需要将数据的一致性、系统可用性、分区容忍性放在天平上一起考虑。 两阶段提交协议简称2PC 是实现分布式事务较为经典的方案但2PC 的可扩展性很差在分布式架构下应用代价较大eBay 架构师Dan Pritchett 提出了BASE 理论用于解决大规模分布式系统下的数据一致性问题。BASE 理论 告诉我们可以通过放弃系统在每个时刻的强一致性来换取系统的可扩展性。 CAP理论 在分布式系统中**一致性Consistency、可用性Availability和分区容忍性Partition Tolerance**三个要素最多只能同时满足两个不可兼得。其中 分区容忍性 又是不可或缺的。 一致性分布式环境下多个节点的数据是否强一致。可用性分布式服务能一直保证可用状态。当用户发出一个请求后服务能在有限时间内返回结果。分区容忍性特指对网络分区的容忍性。即系统中任意信息的丢失或失败不会影响系统的继续运作 BASE 理论 基本可用Basically Available指分布式系统在出现故障时允许损失部分的可用性来保证核心可用。软状态Soft State指允许分布式系统存在中间状态该中间状态不会影响到系统的整体可用性。最终一致性Eventual Consistency指分布式系统中的所有副本数据经过一定时间后最终能够达到一致的状态。
2、两阶段提交2PC 二阶段提交协议Two-phase Commit即 2PC是常用的分布式事务解决方案即 将事务的提交过程分为准备阶段和提交阶段两个阶段来进行处理通过引入协调者Coordinator来协调参与者的行为并最终决定这些参与者是否要真正执行事务。
事务协调者事务管理器事务的发起者 事务参与者资源管理器事务的执行者 准备阶段投票阶段 协调者询问参与者事务是否执行成功参与者发回事务执行结果但该阶段并未提交事务。 1协调者向所有参与者发送事务内容询问是否可以提交事务并等待答复 2各参与者执行事务操作将 undo 和 redo 信息记入事务日志中但不提交事务 3如果参与者执行成功给协调者反馈同意否则反馈终止。 提交阶段执行阶段 如果事务在每个参与者上都执行成功事务协调者发送通知让参与者提交事务否则协调者发送通知让参与者回滚事务。 在准备阶段参与者执行了事务但是还未提交。只有在提交阶段接收到协调者发来的通知后才进行提交或者回滚。 1事务协调者节点向所有参与者节点发出正式提交(commit)的请求 2参与者节点正式完成操作并释放在整个事务期间内占用的资源 3参与者节点向协调者节点发送ACK完成消息 4事务协调者节点收到所有参与者节点反馈的ACK完成消息后完成事务。 2PC优缺 优点 尽量保证了数据的强一致适合对数据强一致要求很高的关键领域。其实也不能100%保证强一致如宕机 缺点 性能问题执行过程中所有参与节点都是事务阻塞型的。当参与者占有公共资源时其他第三方节点访问公共资源不得不处于阻塞状态。 可靠性问题参与者发生故障。协调者需要给每个参与者额外指定超时机制超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。 数据一致性问题二阶段无法解决的问题如协调者在发出commit消息之后宕机而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者这条事务的状态也是不确定的没人知道事务是否被已经提交。 实现复杂牺牲了可用性对性能影响较大不适合高并发高性能场景。
3、三阶段提交3PC 三阶段提交协议是二阶段提交协议的改进版本其有两个改动点。 1在协调者和参与者中都引入超时机制 2在第一阶段和第二阶段中插入一个准备阶段保证了在最后提交阶段之前各参与节点的状态是一致的。 即除了引入超时机制之外3PC把2PC的准备阶段再次一分为二这样三阶段提交就有CanCommit、PreCommit 和 DoCommit 三个阶段。 阶段1CanCommit 事务询问协调者向参与者发送一个CanCommit事务请求询问是否可以执行事务提交操作开始等待参与者的响应。参与者向协调者反馈事务询问响应参与者根据自身情况反馈YES响应进入预备状态否则返回NO响应。 阶段2PreCommit 返回yes情况 1协调者向所有参与者发送PreCommit请求进入准备阶段2参与者收到PreCommit请求后执行事务操作将undo和redo信息记录到日志中。3各参与者向协调者反馈事务执行响应成功响应ACK同时等待最终指令提交还是终止。 返回no情况中断事务 1任一参与者向协调者反馈了 NO响应 或者等待 超时 之后协调者无法接收到所有参与者反馈响应那么中断事务。2发送中断请求abort请求。3参与者收到协调者abort请求或者等待协调者请求超时参与者中断事务。 阶段3DoCommit 同步处理 发送提交请求协调者正常工作状态接收到来自所有参与者的ACK响应那么它将从预提交状态转换为提交状态向所有参与者发送DoCommit请求。事务提交参与者收到DoCommit请求后会正式执行事务提交操作完成提交后释放事务资源。反馈事务提交结果参与者完成事务提交之后向协调者发送ACK消息。完成事务协调者收到所有参与者反馈的ACK消息后完成事务。 回滚处理 发送中断请求协调者向所有参与者发送abort请求。事务回滚参与者收到abort请求后利用 阶段2中的undo日志来执行事务回滚操作完成回滚释放资源。反馈事务回滚结果参与者完成了事务回滚后向协调者发送ACK消息。协调者收到所有参与者反馈的ACK消息后中断事务。 4、Seata分布式事务方案 Seata 是一款开源的分布式事务解决方案致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式为用户打造一站式的分布式解决方案。 Seata术语 TC事务协调者维护全局和分支事务的状态驱动全局事务提交或回滚。TM事务管理器定义全局事务的范围开始全局事务、提交或回滚全局事务RM管理分支事务处理的资源与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。 Seata的2PC方案 一阶段业务数据和回滚日志记录在同一个本地事务中提交释放本地锁和连接资源。二阶段提交异步化非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。一阶段本地事务提交前需要确保先拿到 全局锁 。拿不到全局锁 不能提交本地事务。拿全局锁的尝试被限制在一定范围内超出范围将放弃并回滚本地事务释放本地锁。在数据库本地事务隔离级别读已提交或以上的基础上SeataAT 模式的默认全局隔离级别是 读未提交如果应用在特定场景下必需要求全局的 读已提交 目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。 Seata执行流程分析 每个 RM 使用 DataSourceProxy 链接数据路目的是使用 ConnectionProxy使用数据源和数据代理的目的是在第一阶段将 undo_log 和业务数据放在一个本地事务提交这样就保存了只要有业务操作就一定有 undo_log 在第一阶段 undo_log 中存放了数据修改前后修改后的值为事务回滚做好准别所以第一阶段完成就已经将分支事务提交了也就释放了锁资源 TM 开启全局事务开始将 XID全局事务ID 放在事务上下文中通过 feign 调用也将 XID 传入下游分支事务每个分支事务将自己的 Branch ID 分支事务ID与 XID 关联 第二阶段全局事务提交TC会通知各分支参与者提交分支事务在第一阶段就已经提交了分支事务这里各参与者只需要删除undo_log即可并且可以异步执行第二阶段很快可以完成 如果某一个分支事务异常第二阶段就全局事务回滚操作TC会通知各分支参与者回滚分支事务通过 XID 和 Branch-ID 找到对应的回滚日志通过回滚日志生成的反向SQL并执行以完成分支事务回滚到之前
