分布式事务解决方案

《分布式事务解决方案》由会员分享，可在线阅读，更多相关《分布式事务解决方案（5页珍藏版）》请在装配图网上搜索。

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

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

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

4、否同样的值。(等同于 所有节点访问同一份最新的数据副本)可用性(A):在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。 (对数据更新具备高可用性)分区容忍性(P):以实际效果而言，分区相当于对通信的时限要求。系统如果不能在 时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出 选择。CAP原则的精髓就是要么AP，要么CP，要么AC,但是不存在CAP。如果在某个分布 式系统中数据无副本， 那么系统必然满足强一致性条件，因为只有独一数据，不会出现数 据不一致的情况，此时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）。TCC 事务补偿型方案TCC的全程主要包括Try （尝试）、Confirm （确认）、Cancel （取消）这三个主要阶段。Try阶段：这个阶段是对各个微服务的资源做检测以及对资源进行锁定或者预留 Confirm阶段：这

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

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

13、码完全开源3、基于切面的强一致性事务框架4、高可用，模块可以依赖Dubbo或SpringCloud的集群方式做集群化，TxManager也 可以做集群化5、支持本地事务和分布式事务共存6、事务补偿机制，服务故障或挂机再启动时可恢复事务LCN 框架原理：参考网站：閉直特當地事务匿捉 P&V-hpdate0 :辐用积甘拙口 httWil j i fenC I pent, ddNunb-er int i =1/0：我起序臼建事的疔址”菽取#1井iiiDIcn槪比闭4一相并血务、盘取 爭伽裁畑壬点，$糊处脱务芟此服务掛*羽扌勿，玖请岸才宜松運 戎董雪畫诩爭头1,.用用积冷牛地 赴耳XI切冷怖丸夢轴練理

14、”我齐生严事务，城本地卒齐巖运工”事軒协関者，乐地4爭物&如事输调需(2oakccpr)2.定麗方调用*他風备按u 3界与专，械抽人谒阳我护J核心步骤：1、创建事务组 是指在事务发起方开始执行业务代码之前先调用 TxManager 创建事务 组对象，然后拿到事务标示 GroupId 的过程。2、添加事务组 添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息添 加通知给 TxManager 的操作。3、关闭事务组 是指在发起方执行完业务代码以后，将发起方执行结果状态通知给 TxManager的动作。当执行完关闭事务组的方法以后，TxManager将根据事务组信息来通知 相应的参与模块提交或回滚事务。PS：本文是参考其他文章自己整理出来的，觉得有用，后续会继续修改。目前只是理论, 后续会写实现代码。