本篇文章给大家分享的是有关分布式事务的解决方案有哪些，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
事务，即将一个活动涉及的所有操作作为一个不可分割的执行单元，提供一种“要么一个都不执行，要么全都执行”的机制。在单机系统中，我们很容易能够实现一套满足ACID特性的事务处理系统，但是在分布式系统中，数据分散在各台不同的机器上，如何对这些数据进行分布式事务处理具有非常大的挑战。
1、一个服务操作一个数据库
一个服务一个数据库
一个服务操作一个对应的数据库，这就是我们大多数服务的场景，这种场景的事务很好保证，利用数据库本身的事务特性即可，我们称之为本地事务。
2、同一个服务操作多个数据库
一个服务多个数据库
随着系统功能的增加，数据量的增多，我们可能需要队数据库进行划分，按照划分方式，分为垂直划分和水平划分：
垂直划分
随着服务功能的增多，我们可能会把某些功能方法放到一个单独的其他数据库中，或者我们会直接去访问其他服务的数据库，这时就会操作多个数据库了，我们把这种情况，称为数据库的垂直划分。（其实这种场景不应该存在，因为如果是本服务的，那么就应该是同一个数据库为好；如果是其他的服务，那么不应该直接操作其他服务的数据库，而是应该调用其他服务提供的接口），因此这种场景不是很常见；
水平划分
上面那种场景不常见，但还有一种情况，却是经常遇到的，尤其是数据量很大的情况下。那就是当我们对数据库进行分库分表后，这时候就需要操作多个数据库了，这种情况我们称为水平划分；
3、微服务SOA跨服务调用
微服务调用
上面说到直接操作其他服务的DB，并不合适，正确的方式是使用其他服务提供的接口。
“一个服务操作一个数据库”的场景的事务，我们称之为本地事务；“同一个服务操作多个数据库”和“微服务SOA跨服务调用”这两种的事务，我们称之为分布式事务。
对于本地事务,我们可以利用数据库本身的事务特性保证事务，那么在分布式场景下，我们该如何保证事务了？
谈到事务，就必须知道三个规则，分别是：ACID,CAP和BASE。单机系统一般遵循ACID规则；而分布式系统则一般遵循CAP规则或者BASE规则。
ACID是事务的四个基本性质，属于传统数据库常用的设计理念，追求强一致性模型。ACID是指Atomicity（原子性）、Consistency（一致性）、Isolation（隔离型）、Durability（持久性）：
A：原子性（Atomicity)
一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
C:一致性（Consistency)
事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。
I:隔离型（Isolation)
指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。
D:持久性（Durability)
指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。
CAP
CAP是Consistent(一致性)、Available(可用性)和Partition Tolerance (分区容错性)三个词的缩写：
C (一致性):对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致。
A (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是返回40。
P (分区容错性):当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。
CAP三者不可能共有，一个分布式系统最多只能同时满足一致性（Consistence）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项:
CA without P
这种情况在分布式系统中几乎是不存在的。在分布式环境下，主机众多、部署分散，分区是一个必然的事实。在这个存在分区的事实下，我们选择了CA而放弃了P，那么为了保证一致性，这个时候必须拒绝请求，但是A又不允许。因此在分布式场景下，不可能选择CA架构，只能选择CP或者AP架构。
我们熟知的关系型数据库是CA架构，如My Sql和Oracle就是保证了可用性和数据一致性，但是他并不是个分布式系统。一旦关系型数据库要考虑主备同步、集群部署等就必须要把P也考虑进来。
CP without A
如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。一个保证了CP而一个舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。
设计成CP的系统的，最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况时，优先保证数据的强一致性，代价就是舍弃系统的可用性。如Redis、HBase等，还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。对于大规模金融服务也是，他们必须保证C，同时存在P，因此也只能牺牲A.
AP wihtout C
要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
这种舍弃强一致性而保证系统的分区容错性和可用性的场景和案例非常多。前面我们介绍可用性的时候说到过，很多系统在可用性方面会做很多事情来保证系统的全年可用性可以达到N个9，所以，对于很多业务系统来说，比如淘宝的购物，12306的买票。都是在可用性和一致性之间舍弃了一致性而选择可用性。
你在12306买票的时候肯定遇到过这种场景，当你购买的时候提示你是有票的（但是可能实际已经没票了），你也正常的去输入验证码，下单了。但是过了一会系统提示你下单失败，余票不足。这其实就是先在可用性方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，会影响一些用户体验，但是也不至于造成用户流程的严重阻塞。
但是，我们说很多网站牺牲了一致性，选择了可用性，这其实也不准确的。就比如上面的买票的例子，其实舍弃的只是强一致性。退而求其次保证了最终一致性。也就是说，虽然下单的瞬间，关于车票的库存可能存在数据不一致的情况，但是过了一段时间，还是要保证最终一致性的。
对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。
对于AP来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的BASE也是根据AP来扩展。
BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。
BASE 是指 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)：
基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
软状态:允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。
BASE中用软状态和最终一致，保证了分布死网络延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。
目前分布式事务解决的方案主要有对业务无入侵和有入侵的方案，无入侵方案主要有基于数据库 XA 协议的两段式提交（2PC）方案，它的优点是对业务代码无入侵，但是它的缺点也是很明显：必须要求数据库对 XA 协议的支持，且由于 XA 协议自身的特点，它会造成事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，因此它性能很差，它的存在相当于七伤拳那样“伤人七分，损己三分”，因此在互联网项目中并不是很流行这种解决方案。
为了这个弥补这种方案带来性能低的问题，又想出了很多种方案来解决，但这无一例外都需要通过在应用层做手脚，即入侵业务的方式，比如很出名的 TCC 方案，基于 TCC 也有很多成熟的框架，如 ByteTCC、tcc-transaction 等。以及基于可靠消息的最终一致性来实现，如 RocketMQ 的事务消息。
入侵代码的方案是基于现有情形“迫不得已”才推出的解决方案，实际上它们实现起来非常不优雅，一个事务的调用通常伴随而来的是对该事务接口增加一系列的反向操作，比如 TCC 三段式提交，提交逻辑必然伴随着回滚的逻辑，这样的代码会使得项目非常臃肿，维护成本高。
在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等)。因此，二阶段提交的思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。所谓的两个阶段是指：第一阶段：准备阶段；第二阶段：提交阶段。
事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。
详细步骤如下：
1）协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应；
2）参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志；
3）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。
提交通过
所有的参与者，如果在准备阶段，都返回OK，那么第二阶段均进行提交。
提交通过
提交回滚
所有参与者，在准备阶段，只要有一个返回NO，那么第二阶段就都进行回滚。
提交回滚
单点问题:事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。
同步阻塞:在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。
数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。
总的来说，XA协议比较简单，成本较低，但是其单点问题，以及不能支持高并发(由于同步阻塞)依然是其最大的弱点。
TCC与2PC二阶段提交机制类似，区别在于层面不同，2PC是在数据库层面解决数据库之间的分布式事务，TCC是在应用层面解决分布式系统中的分布式事务。
TCC模式需要事务参与者根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作接口；事务参与者在一阶段中，执行Try方式；在二阶段中，如果是提交，则执行Confirm方法，如果是回滚，则执行 Cancel方法：
Try接口：尝试执行,完成所有业务检查（一致性）,预留必须业务资源（准隔离性）
Confirm接口：确认执行真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm要求一定要成功，因此Confirm失败后需要进行重试。因此Confirm操作需要满足幂等性。
Cancel接口：释放Try阶段预留的业务资源。Cancel操作失败也会一直重试，因此也需要满足幂等性。
举个简单的例子，你去商店用两30块钱买一瓶矿泉水，那么参与方为你和店主，资源为你的钱和老板的水，操作为你付钱，老板收钱和给你水：
第一阶段（try)：各自检查并资源。对于你，你需要检查你钱包里是否够2块钱，如果有那么就要冻结这两块钱；对于老板，它看看冰箱里是不是还要矿泉水，如果有，那么锁定这瓶水。
第二阶段（Confirm)：如果你和老板都检查了，没问题，那么就执行交易Confirm，你付两块钱，老板收到两块钱，并给你一瓶矿矿水。
第二阶段（Cancel)：如果你俩在检查时，操作有失败情况或者超时，则进行cancel，你解冻你的钱，老板的那一瓶水也可以卖给别人了；
对于你这边，详细列出TCC执行过程，如下：
TCC过程示例
用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。
此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。
本地消息表
对于本地消息队列来说核心是把大事务转变为小事务。还是举上面用100元去买一瓶水的例子。
1）当你扣钱的时候，你需要在你扣钱的服务器上新增加一个本地消息表，你需要把你扣钱和写入减去水的库存到本地消息表放入同一个事务(依靠数据库本地事务保证一致性）；
2.这个时候有个定时任务去轮询这个本地事务表，把没有发送的消息，扔给商品库存服务器，叫他减去水的库存，到达商品服务器之后这个时候得先写入这个服务器的事务表，然后进行扣减，扣减成功后，更新事务表中的状态；
3.商品服务器通过定时任务扫描消息表或者直接通知扣钱服务器，扣钱服务器本地消息表进行状态更新；
4.针对一些异常情况，定时扫描未成功处理的消息，进行重新发送，在商品服务器接到消息之后，首先判断是否是重复的，如果已经接收，在判断是否执行，如果执行在马上又进行通知事务，如果未执行，需要重新执行需要由业务保证幂等，也就是不会多扣一瓶水；
本地消息队列是BASE理论，是最终一致模型，适用于对一致性要求不高的。实现这个模型时需要注意重试的幂等。
在RocketMQ中实现了分布式事务，实际上其实是对本地消息表的一个封装，将本地消息表移动到了MQ内部，下面简单介绍一下MQ事务
基本流程如下:
第一阶段Prepared消息，会拿到消息的地址。
第二阶段执行本地事务。
第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。消息接受者就能使用这个消息。
如果确认消息失败，在RocketMq Broker中提供了定时扫描没有更新状态的消息，如果有消息没有得到确认，会向消息发送者发送消息，来判断是否提交，在rocketmq中是以listener的形式给发送者，用来处理。
如果消费超时，则需要一直重试，消息接收端需要保证幂等。如果消息消费失败，这个就需要人工进行处理，因为这个概率较低，如果为了这种小概率时间而设计这个复杂的流程反而得不偿失
Saga是30年前一篇数据库伦理提到的一个概念。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。
每个Saga由一系列sub-transaction Ti 组成 每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果,这里的每个T，都是一个本地事务。可以看到，和TCC相比，Saga没有“预留 try”动作，它的Ti就是直接提交到库。
Saga的执行顺序有两种：
T1, T2, T3, ..., Tn
T1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < n Saga定义了两种恢复策略：
向后恢复，即上面提到的第二种执行顺序，其中j是发生错误的sub-transaction，这种做法的效果是撤销掉之前所有成功的sub-transation，使得整个Saga的执行结果撤销。
向前恢复，适用于必须要成功的场景，执行顺序是类似于这样的：T1, T2, ..., Tj(失败), Tj(重试),..., Tn，其中j是发生错误的sub-transaction。该情况下不需要Ci。
这里要注意的是，在saga模式中不能保证隔离性，因为没有锁住资源，其他事务依然可以覆盖或者影响当前事务。
还是拿100元买一瓶水的例子来说，这里定义
T1=扣100元 T2=给用户加一瓶水 T3=减库存一瓶水
C1=加100元 C2=给用户减一瓶水 C3=给库存加一瓶水
我们一次进行T1,T2，T3如果发生问题，就执行发生问题的C操作的反向。
上面说到的隔离性的问题会出现在，如果执行到T3这个时候需要执行回滚，但是这个用户已经把水喝了(另外一个事务)，回滚的时候就会发现，无法给用户减一瓶水了。这就是事务之间没有隔离性的问题
可以看见saga模式没有隔离性的影响还是较大，可以参照华为的解决方案:从业务层面入手加入一 Session 以及锁的机制来保证能够串行化操作资源。也可以在业务层面通过预先冻结资金的方式隔离这部分资源， 最后在业务操作的过程中可以通过及时读取当前状态的方式获取到最新的更新。
以上就是分布式事务的解决方案有哪些，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
