平面设计网站导航,wordpress 分页无效,常州网站备案,手机ps软件如何做ppt下载网站分布式事务是企业集成中的一个技术难点#xff0c;也是每一个分布式系统架构中都会涉及到的一个东西#xff0c;特别是在这几年越来越火的微服务架构中#xff0c;几乎可以说是无法避免#xff0c;本文就围绕分布式事务各方面与大家进行介绍。 事务 1.1 什么是事务 数据库… 分布式事务是企业集成中的一个技术难点也是每一个分布式系统架构中都会涉及到的一个东西特别是在这几年越来越火的微服务架构中几乎可以说是无法避免本文就围绕分布式事务各方面与大家进行介绍。 事务 1.1 什么是事务 数据库事务简称事务Transaction是指数据库执行过程中的一个逻辑单位由一个有限的数据库操作序列构成。 事务拥有以下四个特性习惯上被称为ACID特性 原子性Atomicity事务作为一个整体被执行包含在其中的对数据库的操作要么全部被执行要么都不执行。 一致性Consistency事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束。除此之外一致性还有另外一层语义就是事务的中间状态不能被观察到这层语义也有说应该属于原子性。 隔离性Isolation多个事务并发执行时一个事务的执行不应影响其他事务的执行如同只有这一个操作在被数据库所执行一样。 持久性Durability已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时此操作将不可逆转。 1.2 本地事务 起初事务仅限于对单一数据库资源的访问控制 架构服务化以后事务的概念延伸到了服务中。倘若将一个单一的服务操作作为一个事务那么整个服务操作只能涉及一个单一的数据库资源 这类基于单个服务单一数据库资源访问的事务被称为本地事务Local Transaction。 分布式事务 本地事务主要限制在单个会话内不涉及多个数据库资源。但是在基于SOAService-Oriented Architecture面向服务架构的分布式应用环境下越来越多的应用要求对多个数据库资源多个服务的访问都能纳入到同一个事务当中分布式事务应运而生。 最早的分布式事务应用架构很简单不涉及服务间的访问调用仅仅是服务内操作涉及到对多个数据库资源的访问。 当一个服务操作访问不同的数据库资源又希望对它们的访问具有事务特性时就需要采用分布式事务来协调所有的事务参与者。 对于上面介绍的分布式事务应用架构尽管一个服务操作会访问多个数据库资源但是毕竟整个事务还是控制在单一服务的内部。如果一个服务操作需要调用另外一个服务这时的事务就需要跨越多个服务了。在这种情况下起始于某个服务的事务在调用另外一个服务的时候需要以某种机制流转到另外一个服务从而使被调用的服务访问的资源也自动加入到该事务当中来。下图反映了这样一个跨越多个服务的分布式事务 如果将上面这两种场景一个服务可以调用多个数据库资源也可以调用其他服务结合在一起对此进行延伸整个分布式事务的参与者将会组成如下图所示的树形拓扑结构。在一个跨服务的分布式事务中事务的发起者和提交均系同一个它可以是整个调用的客户端也可以是客户端最先调用的那个服务。 较之基于单一数据库资源访问的本地事务分布式事务的应用架构更为复杂。 在不同的分布式应用架构下实现一个分布式事务要考虑的问题并不完全一样比如对多资源的协调、事务的跨服务传播等实现机制也是复杂多变。尽管有这么多工程细节需要考虑但分布式事务最核心的还是其 ACID 特性。因此想要了解一个分布式事务就先从了解它是怎么实现事务 ACID 特性开始。 下文将从两个最常见的分布式事务模型入手着重分析分布式事务的基础共通点即如何保证分布式事务的 ACID 特性。 常见的分布式事务解决方案 1.基于XA协议的两阶段提交 XA是一个分布式事务协议由Tuxedo提出。XA中大致分为两部分事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现比如Oracle、DB2这些商业数据库都实现了XA接口而事务管理器作为全局的调度者负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下 总的来说XA协议比较简单而且一旦商业数据库实现了XA协议使用分布式事务的成本也比较低。但是XA也有致命的缺点那就是性能不理想特别是在交易下单链路往往并发量很高XA无法满足高并发场景。XA目前在商业数据库支持的比较理想在mysql数据库中支持的不太理想mysql的XA实现没有记录prepare阶段日志主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA这让XA的应用场景变得非常狭隘。 2.消息事务最终一致性 所谓的消息事务就是基于消息中间件的两阶段提交本质上是对消息中间件的一种特殊利用它是将本地事务和发消息放在了一个分布式事务里保证要么本地操作成功成功并且对外发消息成功要么两者都失败开源的RocketMQ就支持这一特性具体原理如下 1、A系统向消息中间件发送一条预备消息 2、消息中间件保存预备消息并返回成功 3、A执行本地事务 4、A发送提交消息给消息中间件 通过以上4步完成了一个消息事务。对于以上的4个步骤每个步骤都可能产生错误下面一一分析 步骤一出错则整个事务失败不会执行A的本地操作 步骤二出错则整个事务失败不会执行A的本地操作 步骤三出错这时候需要回滚预备消息怎么回滚答案是A系统实现一个消息中间件的回调接口消息中间件会去不断执行回调接口检查A事务执行是否执行成功如果失败则回滚预备消息 步骤四出错这时候A的本地事务是成功的那么消息中间件要回滚A吗答案是不需要其实通过回调接口消息中间件能够检查到A执行成功了这时候其实不需要A发提交消息了消息中间件可以自己对消息进行提交从而完成整个消息事务 基于消息中间件的两阶段提交往往用在高并发场景下将一个分布式事务拆成一个消息事务A系统的本地操作发消息B系统的本地操作其中B系统的操作由消息驱动只要消息事务成功那么A操作一定成功消息也一定发出来了这时候B会收到消息去执行本地操作如果本地操作失败消息会重投直到B操作成功这样就变相地实现了A与B的分布式事务。原理如下 虽然上面的方案能够完成A和B的操作但是A和B并不是严格一致的而是最终一致的我们在这里牺牲了一致性换来了性能的大幅度提升。当然这种玩法也是有风险的如果B一直执行不成功那么一致性会被破坏具体要不要玩还是得看业务能够承担多少风险。 3.TCC 模型 TCCTry-Confirm-Cancel分布式事务模型相对于 XA 等传统模型其特征在于它不依赖资源管理器RM对分布式事务的支持而是通过对业务逻辑的分解来实现分布式事务。 TCC 模型认为对于业务系统中一个特定的业务逻辑其对外提供服务时必须接受一些不确定性即对业务逻辑初步操作的调用仅是一个临时性操作调用它的主业务服务保留了后续的取消权。如果主业务服务认为全局事务应该回滚它会要求取消之前的临时性操作这就对应从业务服务的取消操作。而当主业务服务认为全局事务应该提交时它会放弃之前临时性操作的取消权这对应从业务服务的确认操作。每一个初步操作最终都会被确认或取消。 因此针对一个具体的业务服务TCC 分布式事务模型需要业务系统提供三段业务逻辑 初步操作 Try完成所有业务检查预留必须的业务资源。 确认操作 Confirm真正执行的业务逻辑不作任何业务检查只使用 Try 阶段预留的业务资源。因此只要 Try 操作成功Confirm 必须能成功。另外Confirm 操作需满足幂等性保证一笔分布式事务有且只能成功一次。 取消操作 Cancel释放 Try 阶段预留的业务资源。同样的Cancel 操作也需要满足幂等性。 TCC 分布式事务模型包括三部分 1.主业务服务主业务服务为整个业务活动的发起方服务的编排者负责发起并完成整个业务活动。 2.从业务服务从业务服务是整个业务活动的参与方负责提供 TCC 业务操作实现初步操作Try、确认操作Confirm、取消操作Cancel三个接口供主业务服务调用。 3.业务活动管理器业务活动管理器管理控制整个业务活动包括记录维护 TCC 全局事务的事务状态和每个从业务服务的子事务状态并在业务活动提交时调用所有从业务服务的 Confirm 操作在业务活动取消时调用所有从业务服务的 Cancel 操作。 一个完整的 TCC 分布式事务流程如下 主业务服务首先开启本地事务; 主业务服务向业务活动管理器申请启动分布式事务主业务活动; 然后针对要调用的从业务服务主业务活动先向业务活动管理器注册从业务活动然后调用从业务服务的 Try 接口; 当所有从业务服务的 Try 接口调用成功主业务服务提交本地事务;若调用失败主业务服务回滚本地事务; 若主业务服务提交本地事务则 TCC 模型分别调用所有从业务服务的 Confirm 接口;若主业务服务回滚本地事务则分别调用 Cancel 接口; 所有从业务服务的 Confirm 或 Cancel 操作完成后全局事务结束。 TCC模型小结 所谓的TCC编程模式也是两阶段提交的一个变种。TCC提供了一个编程框架将整个业务逻辑分为三块Try、Confirm和Cancel三个操作。以在线下单为例Try阶段会去扣库存Confirm阶段则是去更新订单状态如果更新订单失败则进入Cancel阶段会去恢复库存。总之TCC就是通过代码人为实现了两阶段提交不同的业务场景所写的代码都不一样复杂度也不一样因此这种模式并不能很好地被复用。 分布式事务总结 分布式事务本质上是对多个数据库的事务进行统一控制按照控制力度可以分为不控制、部分控制和完全控制。不控制就是不引入分布式事务部分控制就是各种变种的两阶段提交包括上面提到的消息事务最终一致性、TCC模式而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好缺点是数据一致性减弱了完全控制则是牺牲了性能保障了一致性具体用哪种方式最终还是取决于业务场景。作为技术人员一定不能忘了技术是为业务服务的不要为了技术而技术针对不同业务进行技术选型也是一种很重要的能力 你可能也喜欢: 阿里P8架构师谈分布式Session共享的4类技术方案与优劣势比较阿里P8架构师谈分布式锁的3种实现数据库、缓存、Zookeeper)阿里P8架构师谈分布式系统全局唯一ID简介、特点、5种生成方式 一篇文章彻底搞懂“分布式事务” 阿里P8架构师谈单点登录的原理、来源、实现、以及技术方案比较 阿里P8架构师谈分布式数据库数据一致性的原理、与技术实现方案
