Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
晶之木
advanced-java
提交
4b5e79bf
A
advanced-java
项目概览
晶之木
/
advanced-java
与 Fork 源项目一致
从无法访问的项目Fork
通知
3
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
A
advanced-java
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
未验证
提交
4b5e79bf
编写于
6月 27, 2020
作者:
Y
Yang Libin
提交者:
GitHub
6月 27, 2020
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
fix: update distributed-transaction.md
上级
ffeb3460
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
25 addition
and
15 deletion
+25
-15
docs/distributed-system/distributed-transaction.md
docs/distributed-system/distributed-transaction.md
+25
-15
未找到文件。
docs/distributed-system/distributed-transaction.md
浏览文件 @
4b5e79bf
## 面试题
分布式事务了解吗?你们是如何解决分布式事务问题的?
## 面试官心理分析
...
...
@@ -11,14 +12,14 @@
分布式事务的实现主要有以下 6 种方案:
*
XA 方案
*
TCC 方案
*
SAGA 方案
*
本地消息表
*
可靠消息最终一致性方案
*
最大努力通知方案
-
XA 方案
-
TCC 方案
-
SAGA 方案
-
本地消息表
-
可靠消息最终一致性方案
-
最大努力通知方案
### 两阶段提交方案/XA方案
### 两阶段提交方案/XA
方案
所谓的 XA 方案,即:两阶段提交,有一个
**事务管理器**
的概念,负责协调多个数据库(资源管理器)的事务,事务管理器先问问各个数据库你准备好了吗?如果每个数据库都回复 ok,那么就正式提交事务,在各个数据库上执行操作;如果任何其中一个数据库回答不 ok,那么就回滚事务。
...
...
@@ -36,9 +37,9 @@
TCC 的全称是:
`Try`
、
`Confirm`
、
`Cancel`
。
*
Try 阶段:这个阶段说的是对各个服务的资源做检测以及对资源进行
**锁定或者预留**
。
*
Confirm 阶段:这个阶段说的是在各个服务中
**执行实际的操作**
。
*
Cancel 阶段:如果任何一个服务的业务方法执行出错,那么这里就需要
**进行补偿**
,就是执行已经执行成功的业务逻辑的回滚操作。(把那些执行成功的回滚)
-
Try 阶段:这个阶段说的是对各个服务的资源做检测以及对资源进行
**锁定或者预留**
。
-
Confirm 阶段:这个阶段说的是在各个服务中
**执行实际的操作**
。
-
Cancel 阶段:如果任何一个服务的业务方法执行出错,那么这里就需要
**进行补偿**
,就是执行已经执行成功的业务逻辑的回滚操作。(把那些执行成功的回滚)
这种方案说实话几乎很少人使用,我们用的也比较少,但是也有使用的场景。因为这个
**事务回滚**
实际上是
**严重依赖于你自己写代码来回滚和补偿**
了,会造成补偿代码巨大,非常之恶心。
...
...
@@ -50,15 +51,21 @@ TCC 的全称是: `Try` 、 `Confirm` 、 `Cancel` 。
![
distributed-transacion-TCC
](
./images/distributed-transaction-TCC.png
)
### Saga方案
金融核心等业务 可能会选择TCC方案,以追求强一致性和更高的并发量,而对于更多的金融核心以上的业务系统 往往会选择补偿事务,补偿事务处理在30多年前就提出了 Saga 理论,随着微服务的发展,近些年才逐步受到大家的关注。目前业界比较公认的是采用 Saga 作为长事务的解决方案。
### Saga 方案
金融核心等业务可能会选择 TCC 方案,以追求强一致性和更高的并发量,而对于更多的金融核心以上的业务系统 往往会选择补偿事务,补偿事务处理在 30 多年前就提出了 Saga 理论,随着微服务的发展,近些年才逐步受到大家的关注。目前业界比较公认的是采用 Saga 作为长事务的解决方案。
#### 基本原理
业务流程中每个参与者都提交本地事务,若某一个参与者失败,则补偿前面已经成功的参与者。下图左侧是正常的事务流程,当执行到 T3 时发生了错误,则开始执行右边的事务补偿流程,反向执行T3、T2、T1 的补偿服务C3、C2、C1,将T3、T2、T1 已经修改的数据补偿掉。
业务流程中每个参与者都提交本地事务,若某一个参与者失败,则补偿前面已经成功的参与者。下图左侧是正常的事务流程,当执行到 T3 时发生了错误,则开始执行右边的事务补偿流程,反向执行 T3、T2、T1 的补偿服务 C3、C2、C1,将 T3、T2、T1 已经修改的数据补偿掉。
![
distributed-transacion-TCC
](
./images/distributed-transaction-saga.png
)
#### 使用场景
对于一致性要求高、短流程、并发高 的场景,如:金融核心系统,会优先考虑 TCC方案。而在另外一些场景下,我们并不需要这么强的一致性,只需要保证最终一致性即可。
比如 很多金融核心以上的业务(渠道层、产品层、系统集成层),这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务。这种情况如果选择TCC方案开发的话,一来成本高,二来无法要求其它公司的服务也遵循 TCC 模式。同时流程长,事务边界太长,加锁时间长,也会影响并发性能。
对于一致性要求高、短流程、并发高 的场景,如:金融核心系统,会优先考虑 TCC 方案。而在另外一些场景下,我们并不需要这么强的一致性,只需要保证最终一致性即可。
比如 很多金融核心以上的业务(渠道层、产品层、系统集成层),这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务。这种情况如果选择 TCC 方案开发的话,一来成本高,二来无法要求其它公司的服务也遵循 TCC 模式。同时流程长,事务边界太长,加锁时间长,也会影响并发性能。
所以 Saga 模式的适用场景是:
...
...
@@ -66,10 +73,13 @@ TCC 的全称是: `Try` 、 `Confirm` 、 `Cancel` 。
-
参与者包含其它公司或遗留系统服务,无法提供 TCC 模式要求的三个接口。
#### 优势
-
一阶段提交本地事务,无锁,高性能;
-
参与者可异步执行,高吞吐;
-
补偿服务易于实现,因为一个更新操作的反向操作是比较容易理解的。
#### 缺点
-
不保证事务的隔离性。
### 本地消息表
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录