【免费】分布式事务解决方案实战1资源-CSDN文库

分布式

需积分: 0 42 浏览量 2022-08-03 15:15:28 上传评论 1 收藏 5.11MB PDF 举报

资源详情

资源评论

资源推荐

分布式事务解决方案实战

1、数据库事务ACID

A:原子性(Atomicity)

一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事

务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过

一样。

就像你买东西要么交钱收货一起都执行，要么要是发不出货，就退钱。

C:一致性(Consistency)

事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完

成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所

有变化将自动地回滚，系统返回到原始状态。

I:隔离性(Isolation)

指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并

发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要

么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数

据。

打个比方，你买东西这个事情，是不影响其他人的。

D:持久性(Durability)

指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动

数据库系统后，数据库还能恢复到事务成功结束时的状态。

打个比方，你买东西的时候需要记录在账本上，即使老板忘记了那也有据可查

2、什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布

式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同

的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质

上来说，分布式事务就是为了保证不同数据库的数据一致性。

3、单体事务和分布式事务

3.1 传统单体架构事务

C (一致性):对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据

上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强

一致，如果有某个节点没有读取到，那就是分布式不一致。

A (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键

一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给

出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的。

P (分区容错性):当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器

网络出现了问题，但是这个集群仍然可以正常工作。

熟悉CAP的人都知道，三者不能共有，在分布式系统中，网络无法100%可靠，分区其实是一个必然现

象，如果我们选择了CA而放弃了P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请

求，但是A又不允许，所以分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。

对于CP来说，放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致。

对于AP来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系

统设计时的选择，后面的BASE也是根据AP来扩展；我们的eureka其实就是追求的高可用性

顺便一提，CAP理论中是忽略网络延迟，也就是当事务提交时，从节点A复制到节点B，但是在现实中这

个是明显不可能的，所以总会有一定的时间是不一致。同时CAP中选择两个，比如你选择了CP，并不是

叫你放弃A。因为P出现的概率实在是太小了，大部分的时间你仍然需要保证CA。就算分区出现了你也

要为后来的A做准备，比如通过一些日志的手段，使其他机器恢复至可用。

4.2 BASE

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个

短语的缩写。是对CAP中AP的一个扩展

基本可用:

分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。

柔性状态:

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。

软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统

在多个不同节点的数据副本存在数据延时。

最终一致性:

系统能够保证在没有其他新的更新操作的情况下，所有节点数据最终一定能够达到一致的状态，

因此所有客户端对系统的数据访问最终都能够获取到最新的值。

BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE

和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许

数据在一段时间内是不一致的，但最终达到一致状态

5、分布式事务解决方案

5.1 XA两阶段提交

流程图

1）、单点问题：事务管理器是整个XA模型的核心，一旦事务协调者节点挂掉，参与者收不到提交或是

回滚通知，参与者会一直处于中间状态无法完成事务。（XA三阶段提交在两阶段提交的基础上增加了

CanCommit阶段，并且引入了超时机制。一旦事物参与者迟迟没有接到协调者的commit请求，会自动

进行本地commit。这样有效解决了协调者单点故障的问题）

2）、同步阻塞：XA协议遵循强一致性。在事务执行过程中，各个节点占用着数据库资源，只有当所有

节点准备完毕，事务协调者才会通知提交，参与者提交后释放资源。这样的过程有着非常明显的性能问

题。（利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性。这个方式避免了像XA协

议那样的性能问题。）

3）、数据不一致：在XA协议的第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消

息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

总的来说，XA协议比较简单，成本较低，但是其单点问题，以及不能支持高并发(由于同步阻塞)依然是

其最大的弱点。

5.2 TCC补偿

核心思想

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿

（撤销）操作。它分为三个阶段：

Try阶段：尝试执行,完成所有业务检查（一致性）,预留必须业务资源（准隔离性）

Confirm阶段：确认执行真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，

Confirm操作满足幂等性。要求具备幂等设计，Confirm失败后需要进行重试。

Cancel阶段：取消执行，释放Try阶段预留的业务资源，Cancel操作满足幂等性并且Cancel阶段的异

常和Confirm阶段异常处理方案基本上一致。

**例如**： A要向 B 转账，思路如下：

我们有一个本地方法，里面依次调用

1、首先在 Try 阶段，要先调用远程接口把 B和 A的钱给冻结起来。

2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。

3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法

(Cancel)。

剩余73页未读，继续阅读

评论收藏

内容反馈

WaiyuetFung

粉丝: 62
资源: 316

分布式事务解决方案实战1

评论0

最新资源

分布式事务解决方案实战1

评论0

分布式事务解决方案

20170830-分布式事务解决方案1

分布式事务解决方案1.pdf

hmily：分布式事务解决方案

常用的分布式事务解决方案

微服务架构的分布式事务解决方案,完整31讲-龙果学院

基于RabbitMQ消息队列的分布式事务解决方案-MQ分布式消息中间件实战.docx

某果学院 微服务分布式事物解决方案

Java分布式实战指南.pdf

分布式事务实战(二) -事务基本概念

分布式事务的解决方案.pdf

seata分布式事务解决方案

分布式事务解决方案.xmind

Spring Cloud Alibaba Seata实现分布式事务

Spring Cloud Alibaba Nacos Seata 分布式微服务实战.pdf

分布式事务之rabbitmq肉身实战

java开发场商城实战教程完整版（20G）

分布式事务的解决方案.docx

分布式事务之解决方案.docx

Dubbo分布式事务解决方案

分布式事务解决方案.docx

分布式事务解决方案.zip

Java思维导图xmind文件+导出图片

SpringCloud Alibaba 实战2021年

2022中国数据库技术大会（公开）PPT汇总（71份）.zip

基于Spring Cloud、OAuth2.0开发基于Vue前后分离的开发平台，支持账号、短信、SSO等多种登录

23讲搞定后台架构实战.txt

最新资源

某果学院微服务分布式事物解决方案