日常提交
This commit is contained in:
22
分布式事务/Saga.md
Normal file
22
分布式事务/Saga.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# 分布式事务: Saga模式
|
||||
## Saga模型
|
||||
- 每个Saga都由一系列子事务Ti组成
|
||||
- 每个子事务Ti都有其对应的补偿动作Ci,补偿操作用于对Ti操作产生的结果进行撤销
|
||||
## Saga的执行顺序
|
||||
1. T1, T2, T3, ... ,Tn(全部执行成功)
|
||||
2. T1, T2, T3, ..., Tj, Cj, Cj-1,... , C1 (执行出错之后回滚之前所有成功的子事务)
|
||||
## 执行出错时,Saga的恢复策略
|
||||
1. 向后恢复(backword recovery),对所有已经完成的子事务进行补偿操作,任一子事务Ti执行失败,撤销掉之前所有执行成功的子事务,使得整个Saga的执行结果都撤销
|
||||
2. 向前恢复(forward recovery),重新尝试失败的事务。假设每个事务最终都会执行成功。其执行顺序为T1, ... Tj(失败), Tj(重试),...,...,Tn。该种情况下并不需要Ci操作对子事务Ti的操作结果进行撤销
|
||||
## Saga模式的结构
|
||||
Saga的嵌套结构只允许存在两个层次:
|
||||
1. 顶层的Saga
|
||||
2. 简单的子事务
|
||||
## Saga特性
|
||||
- 在外层(各个Sagas都在执行时,各个Sagas在执行过程中已经提交的子事务Ti,其执行结果对其他Sagas可见),隔离性并无法被满足,Sagas可能看到其他Sagas的执行结果
|
||||
- 每个子事务都是一个独立事务,各个子事务为独立的原子行为
|
||||
## Saga ACID
|
||||
- 原子性:正常情况下可以保证
|
||||
- 一致性:执行过程中,可能会有A库和B库违反一致性要求的情况,但是最终成功之后是一致的
|
||||
- 隔离性:Sagas A能看到Sagas B部分执行的执行结果
|
||||
- 持久性:对于Sagas中的子事务Ti,其执行完成之后就会commit,而其撤销操作则是会调用Ci对已经提交的操作进行撤销操作
|
||||
32
分布式事务/TCC.md
Normal file
32
分布式事务/TCC.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# 分布式事务: TCC模式
|
||||
## TCC事务
|
||||
TCC是Try、Confirm、Cancel三个单词的首字母缩写,TCC分为三个阶段:预处理(Try)、确认(Confirm)、撤销(Cancel)。
|
||||
## TCC工作流
|
||||
## 预处理阶段(Try phase)
|
||||
在预处理阶段,请求者会请求服务的提供者做一些尝试性的操作。在该阶段,服务提供者会完成一些业务检查与验证,并且预占需要的业务资源。
|
||||
## 确认阶段(Confirm phase)
|
||||
- 如果服务提供者成功执行了Try阶段,并且请求者决定继续执行操作,那么请求者可以在确认阶段执行确认操作。
|
||||
- ***具体的业务在确认阶段被执行***。
|
||||
- 在确认阶段,不会执行更多的验证操作,所有验证操作都会在Try阶段执行
|
||||
- 在Confirm阶段,只会使用Try阶段预留的业务资源
|
||||
> 通常,认为Confirm阶段是不会执行失败的,如果Try阶段被成功执行,那么Confirm阶段也能成功执行,如果Try成功而Confirm执行失败,会对Confirm阶段进行重试
|
||||
## 撤销阶段(Cancel phase)
|
||||
在撤销阶段,如果Try阶段未正确完成且请求者决定不再继续执行,请求者可以在服务提供者上执行撤销操作。在Try阶段预占的业务资源应该在撤销阶段被正确释放
|
||||
***撤销阶段(Cancel)是对预处理阶段(Try)的反向操作***
|
||||
## TCC事务
|
||||
对于TCC事务,全局事务管理器首先会发起所有分支事务的Try操作
|
||||
- 若任何一个分支事务的Try操作执行失败,都会导致所有分支事务的Cancel操作被执行
|
||||
- 若所有分支事务的Try操作都执行成功,那么全局事务管理器会发起所有分支事务的Confirm操作
|
||||
在执行分支事务Confirm/Cancel操作时,如果执行失败,那么全局事务管理器会对失败操作进行重试
|
||||
> 通常,Cancel阶段也被认为是一定执行成功的,如果在Cancel执行时发生错误,需要进行重试或进行人工处理
|
||||
## TCC事务中需要注意的要点
|
||||
### 空回滚
|
||||
若是在没有调用TCC Try阶段的情况下直接调用二阶段的Cancel方法,Cancel方法需要识别出之前并未调用过Try阶段方法,直接返回Cancel成功
|
||||
### 幂等
|
||||
由于在各阶段执行时都存在重试机制,故而要保证Try、Confirm、Cancel接口都要保证幂等性,保证占用资源或释放资源的操作不会被重复执行
|
||||
### 悬挂
|
||||
在RPC调用过程中,由于网络拥堵等原因,Cancel操作可能先于Try操作执行。
|
||||
> 1. 如果先调用Try时,网络拥堵发生超时,那么TM会通知RM回滚分布式事务,调用Cancel操作
|
||||
> 2. 因为网络拥堵,可能调用完Cancel后,RPC的Try请求才到来
|
||||
> 3. 此时到来的Try请求会预留资源,而预留资源无法被其他事务所使用
|
||||
|
||||
Reference in New Issue
Block a user