From 4b5e79bf70857c145181cc4711bda0af15c7eac1 Mon Sep 17 00:00:00 2001 From: Yang Libin Date: Sat, 27 Jun 2020 22:22:07 +0800 Subject: [PATCH] fix: update distributed-transaction.md --- .../distributed-transaction.md | 40 ++++++++++++------- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/docs/distributed-system/distributed-transaction.md b/docs/distributed-system/distributed-transaction.md index cd3ebd4..a0702d3 100644 --- a/docs/distributed-system/distributed-transaction.md +++ b/docs/distributed-system/distributed-transaction.md @@ -1,4 +1,5 @@ ## 面试题 + 分布式事务了解吗？你们是如何解决分布式事务问题的？ ## 面试官心理分析 @@ -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 模式要求的三个接口。 #### 优势 + - 一阶段提交本地事务，无锁，高性能； - 参与者可异步执行，高吞吐； - 补偿服务易于实现，因为一个更新操作的反向操作是比较容易理解的。 + #### 缺点 + - 不保证事务的隔离性。 ### 本地消息表 -- GitLab