分布式事务解决方案_第1页
分布式事务解决方案_第2页
分布式事务解决方案_第3页
分布式事务解决方案_第4页
分布式事务解决方案_第5页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、分布式事务解决方案事务的概念事务就是多个原子操作的组合,他们就像是一条绳上的蚂蚱,要么一起生,要么一起死, 在事务中,如果其中一个操作执行失败,那么剩下的操作都不再执行,而之前执行过的操作 也需要回滚。至于分布式事务,顾名思义就是包含对分布式系统中不同节点的操作的事务。我们使用事务的目的是为了防止一些执行失败的操作对数据造成影响,产生错误数据。 比拟典型的例子就是转账、下订单等关于交易的事务。比方转账业务,我们从A账户转账 500块钱给B账户,那么这一条事务的操作就是:从A账户减去500块钱;向B账户中增 加500块钱。如果我们执行第一个操作成功,从A账户中扣除了 500块钱,但是执行第二 个

2、操作失败,B账户中没有增加500块钱。这样子就产生了错误数据,500块钱“凭空消失” 了。这时我们就需要使用事务,当第二个操作执行失败后,我们将第一个操作进行回滚,将 从A账户中减去的500块钱“还回去”,这样子就保证了数据的正确性。事务的特性事务有原子性、一致性、隔离性、持久性四个特性,取英文名的首字母,简称为ACID 特性。.原子性(atomicity): 一个事务是一个不可分割的工作单位,事务中包括的诸操作要么 都做,要么都不做。.一致性(consistency):事务必须是使数据库从一个一致性状态变到另一个一致性状态。 一致性与原子性是密切相关的。.隔离性(isolation): 一个

3、事务的执行不能被其他事务干扰。即一个事务内部的操作及使 用的数据对并发的其他事务是隔离的,并发执行的各个事务之间不能互相干扰。.持久性(durability):持久性也称永久性,指一个事务一旦提交,它对数据库中数据的 改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。CAP原那么CAP原那么又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用 性(Availability)、分区容错性(Partition tolerance) o CAP原那么指的是,这三个要素最多 只能同时实现两点,不可能三者兼顾。一致性(C):在分布式系统中的所有数据备份,在同一

4、时刻是否同样的值。(等同于 所有节点访问同一份最新的数据副本)可用性(A):在集群中一局部节点故障后,集群整体是否还能响应客户端的读写请求。 (对数据更新具备高可用性)分区容忍性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在 时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出 选择。CAP原那么的精髓就是要么AP,要么CP,要么AC,但是不存在CAPo如果在某个分布式系统中数据无副本,那么系统必然满足强一致性条件,因为只有独一数据,不会出现数 据不一致的情况,此时C和P两要素具备,但是如果系统发生了网络分区状况或者宕机, 必然导致某些数据不可以访

5、问,此时可用性条件就不能被满足,即在此情况下获得了 CP系 统,但是CAP不可同时满足。BASE理论BASE Basically Available (基本可用)、Soft state (软状态)Eventually consistent (最终一致性)三个短语的简写。BASE理论是对CAP中的一致性和可用性进行一个权衡的结果,理论的核心思想就 是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系 统到达最终一致性。基本可用是指分布式系统在出现不可预知故障的时候,允许损失局部可用性一一但请注 意,这绝不等价于系统不可用。弱状态也称为软状态,和硬状态相对,是指允许系统

6、中的数据存在中间状态,并认为该 中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数 据听不的过程存在延时。最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够到达 一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够到达一致,而不需 要实时保证系统数据的强一致性。分布式事务产生的场景一、数据库拆分:单体系统访问多个数据库实例。随着用户增多,数据库压力越来越大,此时我们会进行数据库的拆分,怎么拆分呐?比 如:拆分成用户数据库、商品数据库、订单数据库。此时数据库由原先的单库,被拆分成3 个数据库。单体系统需要访问多个数据库时就会产生分布

7、式事务。产生原因:由于数据分布在不同的数据库实例,需要通过不同的数据库连接去操作数据, 此时就会产生分布式事务。简单理解:跨数据库实例产生分布式事务。二、服务拆分:多服务访问同一个数据库实例随着模块越来越多,工程越来越庞大,我们会将模块拆分成不同的工程,那么两个服务 需要跨网络远程调用,两个服务持有了不同的数据库连接进行数据库操作,此时就会产生分 布式事务。简单理解:跨网络远程调用产生分布式事务。三、服务+数据库拆分:微服务架构随着工程的开展,到了后期,我们就会一个服务一个数据库,比方:用户服务对应一个 用户数据库,商品服务对应一个商品数据库,订单服务对应一个订单数据库,这就是微服务 的产生,

8、微服务之间通过远程调用完成事务操作,这就产生了分布式事务。简单理解:跨网络远程调用产生分布式事务。综上:两种情况会产生分布式事务:1、跨网络远程调用完成事务协作,就会产生分布式事务。2、跨数据库实例完成事务协作,就会产生分布式事务。上面这两种情况有一个共性就是在一个事务中,数据库的连接是不一样的,所以简单理 解就是:一个事务中,当操作使用了不同的数据库连接就会产生分布式事务。解决方案基于可靠消息的最终一致性方案可靠消息最终一致性方案的主要思路如下:A系统首先发送一个prepared消息到消息服务mq,如果这个prepared消息发送失败, 那么就直接取消操作,不再进行任何操作执行了。如果这个消

9、息发送成功过了,那么接着执行本地事务,如果成功就告诉消息服务mq发 送确认消息、,如果失败就告诉消息服务mq回滚消息如果发送了确认消息,那么此时B系统会接收到确认消息,然后执行本地的事务消息服务mq会自动定时轮询所有prepared消息回调相应服务接口,询问这个消息是不 是本地事务处理失败了,所以没发送确认消息?是继续重试还是回滚? 一般来说可以查下数 据库查看之前的本地事务是否执行,如果回滚了,那么这里也回滚吧。这个就是防止可能本 地事务执行成功了,而确认消息发送失败了。可靠消息最终一致性方案里要是系统B的事务失败了怎么办?重试咯,自动不断重试 直到成功,如果实在是不行,要么就是针对重要的资

10、金类业务进行回滚,比方B系统本地 回滚后,想方法通知系统A也回滚;或者是发送报警由人工来手工回滚和补偿。可靠消息最终一致性方案使用场景比拟广泛,适合于对实时性要求不高、比拟耗时的应 用场景。通过消息中间件做成异步调用,发送一个消息出去,人家服务消费消息来执行业务 逻辑。可用RocketMQ的分布式事务实现可靠消息最终一致性方案(RocketMQ=可靠消息服 务+MQ) oTCC事务补偿型方案TCC的全程主要包括Try (尝试)、Confirm (确认)、Cancel (取消)这三个主要阶段。Try阶段:这个阶段是对各个微服务的资源做检测以及对资源进行锁定或者预留Confirm阶段:这个阶段主要

11、是在各个微服务中执行实际的业务操作Cancel阶段:如果任何一个微服务的业务方法执行出现错误,那么这里就需要进行补偿, 就是执行已经执行成功的业务逻辑的进行回滚操作。TCC方案很少用人使用,因为事务回滚操作实际上是严重依赖于手动编写代码来进行 回滚和补偿操作,这样的话就会造成补偿代码过多,使得工程非常难以维护。比拟适合的场 景就是除非真的一致性要求非常高,是系统中的核心业务场景,例如常见的就是资金类的场 景,那可以用TCC方案。最大努力通知型实现:业务活动的主动方在完成处理之后向业务活动的被动方发送消息,允许消息丧失。 业务活动的被动方根据定时策略,向业务活动的主动方查询,恢复丧失的业务消息、

12、。约束:被动方的处理结果不影响主动方的处理结果。本钱:业务查询与校对系统的建设本钱。使用范围:对业务最终一致性的时间敏感度低。跨企业的业务活动。特点:业务活动的主动方在完成业务处理之后,向业务活动的被动方发送通知消息。主 动方可以设置时间阶梯通知规那么,在通知失败后按规那么重复通知,知道通知N次后不再通 知。主动方提供校对查询接口给被动方按需校对查询,用户恢复丧失的业务消息。 适用范围:银行通知,商户通知。使用LCN框架解决分布式事务官网: :/ txlcn. org/zh-cn/Git 地址: s :/github. com/codingapi/txTcn特点:1、兼容 SpringClou

13、d、Dubbo2、使用简单,低依赖,代码完全开源3、基于切面的强一致性事务框架4、高可用,模块可以依赖Dubbo或SpringCloud的集群方式做集群化,TxManager也 可以做集群化5、支持本地事务和分布式事务共存6、事务补偿机制,服务故障或挂机再启动时可恢复事务LCN框架原理:参考 网站: s:github /codingapi/tx-lcn/wiki/LCN%E5%8E%9F%E7%90%86. Icn分布式事物原理“我不生产事务,我本地事务搬运工” 事务协调者、本地.发起方一调用其他服务接口.参与方,祓别人调用我号J4.4.事物分组4.事物分组事物协调者(Zookeepr4.事物

14、分组支村服务积分服务一调用支付本地事务数据& pay.update 0:/调用积分接口 htt协议 j ifenCI ient. addNumber ( J int i =1/0;支村服务积分服务一调用支付本地事务数据& pay.update 0:/调用积分接口 htt协议 j ifenCI ient. addNumber ( J int i =1/0;将事物分组,以诂求方式传递 给积分事物2. 即议请求头发起方创迂事物分如,获取划分组IDaddNumber.调用积分本地 数据再len假关闭核心步骤:1、创立事务组是指在事务发起方开始执行业务代码之前先调用TxManager创立事务组对象,然后拿到事务

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论