创建设计公司网站做设计什么设计比较好的网站

当前位置： 首页 > news >正文

创建设计公司网站,做设计什么设计比较好的网站,asp.net 网站图标,深圳建网站价格目录 一、分布式事务二、分布式事务的解决方案1. 全局事务#xff08;1#xff09;DTP模型#xff08;2#xff09; 两阶段提交协议#xff08;2PC#xff09;原理二阶段提交的缺点 #xff08;3#xff09;三阶段提交协议#xff08;3PC#xff09;原理 2. 基于可靠… 目录 一、分布式事务二、分布式事务的解决方案1. 全局事务1DTP模型2 两阶段提交协议2PC原理二阶段提交的缺点 3三阶段提交协议3PC原理 2. 基于可靠消息服务3. 最大努力通知4. TCC 一、分布式事务 事务指的是一组操作要么全部成功要么全部失败。事务有四个特性ACID具体涵义参考数据库原理这篇博客 这里举一个银行转账的例子来说明本地事务和分布式事务的区别。 本地事务可依赖数据库本身提供的事务特性来实现因此以下逻辑可以控制本地事务 begin transaction//1.本地数据库操作张三减少金额//2.本地数据库操作李四增加金额 commit transation;但是在分布式环境下会变成下边这样 begin transaction//1.本地数据库操作张三减少金额//2.远程调用让李四增加金额 commit transation;可以设想当远程调用让李四增加金额成功了由于网络问题远程调用并没有返回此时本地事务提交失败就回滚了张三减少金额的操作此时张三和李四的数据就不一致了。 ​ 因此在分布式架构的基础上传统数据库事务就无法使用了张三和李四的账户不在一个数据库中甚至不在一个应用系统里实现转账事务需要通过远程调用由于网络问题就会导致分布式事务问题。 二、分布式事务的解决方案

1. 全局事务 1DTP模型 DTP模型规定了要实现分布式事务的体系结构包含多个协议、算法和机制等以确保分布式环境下的事务能够以一致和可靠的方式执行。 它规定了要实现分布式事务需要三种角色 APApplication 应用系统它就是我们开发的业务系统在我们开发的过程中可以使用资源管理器提供的事务接口来实现分布式事务。 TMTransaction Manager 事务管理器 提供分布式事务的操作接口供业务系统调用。这些接口称为TX接口事务管理器管理着所有的资源管理器通过它们提供的XA接口来同一调度这些资源管理器DTP只是一套实现分布式事务的规范并没有定义具体如何实现分布式事务可采用2PC、3PC、Paxos等协议实现 RMResource Manager 资源管理器 能够提供数据服务的对象都可以是资源管理器比如数据库、消息中间件、缓存等资源管理器能够提供单数据库的事务能力它们通过XA接口将本数据库的提交、回滚等能力提供给事务管理器调用以帮助事务管理器实现分布式的事务管理XA是DTP模型定义的接口用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力DTP只是一套实现分布式事务的规范RM具体的实现是由数据库厂商来完成的
   DTP主要侧重于业务实现分布式事务时的体系结构而后面介绍的2PC和3PC则侧重于实现的逻辑相当于DTP是壳而2PC/3PC等协议是核。 举个例子在通信的场景下DTP的作用相当于定义了通信中需要有发送方和接受方要求这两方都需要有发送和接收的能力要求通过一系列的通信方式使得他们能正常通话。而2PC/3PC则是相当于定义了具体的通信逻辑比如TCP三次握手和IP协议等等。 2 两阶段提交协议2PC 原理 两阶段提交又称 2PC是一个非常经典的强一致、中心化的原子提交协议。两阶段提交协议经常用来实现分布式事务。 2PC协议中节点分为两种角色 事务协调者协调事务的功能通常一个系统中只有一个事务参与者一般包含多个 将整个事务流程分为两个阶段 准备阶段Prepare phase事务协调者给每个参与者发送Prepare消息每个参与者要么直接返回失败(如权限验证失败)要么在本地执行事务操作如写本地的redo和undo日志但不提交到达一种“万事俱备只欠东风”的状态 事务询问协调者向所有的参与者发送事务预处理请求并开始等待各参与者的响应执行本地事务各个参与者节点执行本地事务操作但在执行完成后并不会真正提交数据库本地事务各参与者向协调者反馈事务询问的响应各参与者根据自身事务执行情况反馈成功反馈yes失败返回no 提交阶段commit phase根据不同的情况做出相应的操作 所有的参与者反馈给协调者的信息都是 Yes则执行事务提交有一个或者多个返回 No或有超时回滚 二阶段提交的缺点 性能问题执行过程中所有参与节点都是事务阻塞型的。当参与者占有公共资源时其他第三方节点访问公共资源不得不处于阻塞状态。也就是说从投票阶段到提交阶段完成这段时间资源是被锁住的对性能影响比较大。单点故障主要指协调者发生故障这种情况下参与者会一直阻塞下去尤其在第二阶段协调者发生故障那么所有的参与者还都处于锁定事务资源的状态中而无法继续完成事务操作。网络分区是会数据不一致阶段二中当协调者向参与者发送commit请求之后发生了网络分区那就只有一部分参与者执行了commit产生了数据不一致的情况 3三阶段提交协议3PC 原理 三阶段提交Three-phase commit是二阶段提交2PC的改进版本。三阶段提交协议3PC主要是为了解决两阶段提交协议的单点故障阻塞问题2PC 存在的问题是当协调者崩溃时参与者可能在协调者恢复之前保持阻塞。 增加的改进措施 增加超时机制不只有协调者能感知参与者的超时参与者也能感知协调者的超时当其超时时就释放自身的资源不再继续阻塞在准备阶段前多加了一个准备阶段变成有 CanCommit、PreCommit、DoCommit 三个阶段 过程 CanCommit 阶段协调者向参与者发送commit请求参与者如果可以提交就返回Yes响应否则返回No响应这个过程很轻量比如尝试获取数据库锁 事务询问协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应响应反馈参与者接到CanCommit请求之后正常情况下如果其自身认为可以顺利执行事务则返回Yes响应并进入预备状态。否则反馈No PreCommit阶段根据第一阶段接受到的结果采取相应操作 都是yes进行预执行参与者进行事务预提交相应反馈有no或超时参与者中断事务释放其资源 doCommit阶段该阶段进行真正的事务提交也可以分为以下两种情况 执行提交协调者发送事务commit通知参与者执行commit操作反馈中断事务协调者没有收到所有的ack或者有超时情况中断事务参与者进行事务的rollback
   几种情况示意图如下
   
2. 基于可靠消息服务 通过消息中间件来实现。 假设有A和B两个系统分别可以处理任务A和任务B。此时系统A中存在一个业务流程需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。 在系统A处理任务A前首先向消息中间件发送一条消息消息中间件收到后将该条消息持久化但并不投递。此时下游系统B仍然不知道该条消息的存在。消息中间件持久化成功后便向系统A返回一个确认应答系统A收到确认应答后则可以开始处理任务A任务A处理完成后向消息中间件发送Commit请求。该请求发送完成后对系统A而言该事务的处理过程就结束了此时它可以处理别的任务了。消息中间件收到Commit指令后便向系统B投递该消息从而触发任务B的执行当任务B执行完成后系统B向消息中间件返回一个确认应答告诉消息中间件该消息已经成功消费此时这个分布式事务完成。 总结一下上述过程的特点 消息中间件扮演者分布式事务协调者的角色。系统A完成任务A后到任务B执行完成之间会存在一定的时间差。在这个时间差内整个系统处于数据不一致的状态但这短暂的不一致性是可以接受的因为经过短暂的时间后系统又可以保持数据一致性满足BASE理论。 上述过程中如果任务A处理失败那么需要进入回滚流程如下图所示 向消息中间件发送Rollback请求。和发送Commit请求一样系统A发完之后便可以认为回滚已经完成它便可以去做其他的事情。消息中间件收到回滚请求后直接将该消息丢弃而不投递给系统B从而不会触发系统B的任务B Commit和Rollback指令都有可能在传输途中丢失当出现这种情况的时候消息中间件通过超时询问机制保证事务的一致性 询问的结果有三种 提交若获得的状态是“提交”则将该消息投递给系统B。回滚若获得的状态是“回滚”则直接将条消息丢弃。处理中若获得的状态是“处理中”则继续等待。 为保证一致性消息中间件必须确保发送的消息能被下游接收到如果超时就会重传直到得到应答 3. 最大努力通知 是最简单的一种柔性事务适用于一些最终一致性时间敏感度低的业务。 最大努力通知型的实现方案一般符合以下特点 ​ 1、不可靠消息业务活动主动方在完成业务处理之后向业务活动的被动方发送消息直到通知N次后不再通知允许消息丢失(不可靠消息)。 ​ 2、定期校对业务活动的被动方根据定时策略向业务活动主动方查询(主动方提供查询接口)恢复丢失的业务消息。
3. TCC TCC分别对应Try、Confirm和Cancel三种操作 Try预留业务资源Confirm确认执行业务操作Cancel取消执行业务操作 TCC实际上把数据库层的二阶段提交上提到了应用层来实现即Try、Confirm和Cancel操作功能需业务提供