分布式事务处理方式

时间 2019-11-17

标签分布式事务处理方式栏目系统架构繁體版

原文原文链接

分布式事务的典型处理方式

柔性事务和刚性事务

柔性事务知足BASE理论（基本可用，最终一致）。mysql

刚性事务知足ACID理论。sql

在分布式事务当中主要讨论的是柔性事务的处理方式。数据库

柔性事务分为：服务器

两阶段提交型（2PC）
三阶段提交型（3PC）
补偿型（TCC、SAGA）

两阶段提交（2PC）型

两阶段提交(2-Phase Commit, 2PC)是一种比较简单的分布式一致性协议。网络

2PC协议中，每一个事务须要一个协调者来协调各个参与者。每一个事务分为两步执行。分布式

阶段一: 事务请求
1. 协调者向全部参与者发送事务内容，询问是否能够执行事务操做。
2. 各参与者执行事务，写事务日志但不进行提交。各参与者锁定事务相关的资源，保证事务能够正常提交。
3. 各参与者向协调者返回响应，YES表示能够提交，NO表示不能够提交。若协调者收到全部参与者的YES回复，则准备进行事务提交。如有参与者回复NO或者超时，则准备回滚事务。
阶段二: 提交事务
1. 协调者向全部参与者发送提交请求
2. 参与者正式提交事务，并在完成后释放相关资源。
3. 参与者向协调者回复ACK，协调者收到全部参与者的ACK后认为事务提交成功。
回滚事务
1. 在事务请求阶段如有参与者回复NO或者超时，协调者向全部参与者发出回滚请求
2. 各参与者执行事务回滚，并在完成后释放相关资源。
3. 参与者向协调者回复ACK，协调者收到全部参与者的ACK后认为事务回滚成功。

2PC是一种简单的一致性协议，它存在一些问题:优化

单点服务: 若协调者忽然崩溃则事务流程没法继续进行或者形成状态不一致
没法保证一致性: 若协调者第二阶段发送提交请求时崩溃，可能部分参与者收到COMMIT请求提交了事务，而另外一部分参与者未收到请求而放弃事务形成不一致现象。
阻塞: 为了保证事务完成提交，各参与者在完成第一阶段事务执行后必须锁定相关资源直到正式提交，影响系统的吞吐量。

参与者在完成阶段一的事务执行后等待协调者的下一个请求，若协调者超时则能够自行放弃事务。日志

这种方案仍然有没法保证一致性的缺点，但并不会出现某些资料所述一直锁定资源，没法继续的状况。code

三阶段提交（3PC）型

三阶段提交协议(3-Phase Commit, 3PC)进一步将事务请求分为两个阶段，能够解决2PC协议阻塞的问题但没法解决单点服务和不一致的问题。blog

3PC协议下事务分三步提交:

CanCommit
1. 协调者向全部参与者发送CanCommit请求
2. 各参与者判断是否能够完成事务提交，但不执行事务也不锁定资源
3. 各参与者根据是否能够完成事务向协调者回复YES或NO
PreCommit
1. 协调者向全部参与者发送PreCommit请求，执行事务预提交
2. 各参与者执行事务，写事务日志但不进行提交。各参与者锁定事务相关的资源，保证事务能够正常提交。
3. 各参与者向协调者返回响应。若协调者收到全部参与者的YES回复，则准备进行事务提交。如有参与者回复NO或者超时，则放弃事务。
DoCommit
1. 协调者向全部参与者发送提交请求
2. 参与者正式提交事务，并在完成后释放相关资源。
3. 参与者向协调者回复ACK，协调者收到全部参与者的ACK后认为事务提交成功。如有参与者回复NO或者超时，则回滚事务。
4. 参与者进入 PreCommit 状态后，若始终未收到协调者的 DoCommit 请求则会超时后自动执行提交。

三阶段提交协议在CanCommit阶段不锁定资源，解决了阻塞下降吞吐量的问题。

若某个参与者进入 PreCommit 后始终未收到协调者的进一步指令则会自动提交，该策略必定程度上避免协调者单点服务问题。

可是 3PC 仍然没法解决数据不一致问题。

事务补偿型

TCC型事务（Try/Confirm/Cancel）能够归为补偿型。补偿型的例子，在一个长事务（ long-running ）中，一个由两台服务器一块儿参与的事务，服务器A发起事务，服务器B参与事务，B的事务须要人工参与，因此处理时间可能很长。若是按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不容许其余应用访问到事务过程当中的中间结果，直到整个事务被提交或者回滚。这就形成事务A中的资源被长时间锁定，系统的可用性将不可接受。

WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。仍是上面的例子，服务器A的事务若是执行顺利，那么事务A就先行提交，若是事务B也执行顺利，则事务B也提交，整个事务就算完成。可是若是事务B执行失败，事务B自己回滚，这时事务A已经被提交，因此须要执行一个补偿操做，将已经提交的事务A执行的操做做反操做，恢复到未执行前事务A的状态。这样的SAGA事务模型，是牺牲了必定的隔离性和一致性的，可是提升了long-running事务的可用性。

TCC事务

TCC 将事务提交分为 Try - Confirm - Cancel 3个操做。

Try：预留业务资源/数据效验
Confirm：确认执行业务操做
Cancel：取消执行业务操做，回收资源

TCC优势：让应用本身定义数据库操做的粒度，使得下降锁冲突、提升吞吐量成为可能。

TCC不足之处：

对应用的侵入性强。业务逻辑的每一个分支都须要实现try、confirm、cancel三个操做，应用侵入性较强，改形成本高。
实现难度较大。须要按照网络状态、系统故障等不一样的失败缘由实现不一样的回滚策略。为了知足一致性的要求，confirm和cancel接口必须实现幂等。

流程：

发起方发送 try 给全部参与者
参与者执行 try, 尝试预留资源, 并返回给发起者
发起者接收全部参与者的返回信息
发起者发送 commit/cancel指令给参与者
参与者执行commit/cancel, 并返回执行结果
发起者接受参与者的结果

例子：

购买从广州到北京的机票, 由于购买不到直达的机票, 因此购买广州->上海->北京, 在上海中转

广州->上海南航

上海->北京东航

由于不属于同一个航空公司, 因此须要分别购买

若是订票系统依次购买, 可能存在第一家购买成功, 第二家购买失败, 这事不能接受的

因此订票系统先向两家航空公司发送请求, 肯定是否有足够的余票, 并让对方预留票

若是两边都返回预留成功, 订票系统就同时向两边发送请求, 进行确认购票
- 若是订票系统迟迟没有成功发送确认指令, 预留的票会被航空公司自动取消
若是任何一家航空公司返回预留失败, 订票系统就向全部航空公司发送请求, 进行取消全部已经预留的票

与 2PC 的比较

	TCC	2PC
第一阶段	Try: 请求原业务方预留资源	Prepare: 询问是否能够进行提交
段二阶段(成功)	Confirm:确认执行	Commit: 提交事务
第二阶段(失败)	Cancel: 取消执行资源操做	Rollback: 回滚事务

2PC 是资源层面的, 基于数据库底层 (好比mysql的xa事务), 开发者不可感知, 无侵入性

TCC 是业务层面, 开发者可感知, 能够根据业务对事务作特定的优化

存在的问题

存在和 2PC 相似的问题

若是发起者发送 confirm 过程失败, 致使有的参与者接收到指令, 执行了comfirm

而有的参与者因为没有接收到指令, 而由于timeout, 执行了cancel

破坏了整个系统的数据一致性

Saga

背景：

一直以来, 执行数据库事务都是使用 LLT (long lived transaction), 即跨越多个数据库事务的事务, 一次性完成全部事务, 其中不容许其余事务打断, 使用这种机制, 能够保证数据库的数据一致性

可是会带来几个问题:

LLT 可能会涉及到大量的数据库实例, 须要对其进行封锁, 不容许其余事务进行访问, 但因为 LLT 经常须要消耗大量的时间, 可能形成其余事务长期得不到资源, 而处于阻塞状态
可能出现两个 LLT 各自封锁了部分实例, 可是都达不到各自执行的要求, 两方出现死锁

简述

而 Saga 模式是为了弥补 LLT 的缺陷

Saga 模式将一个长事务分割多个子事务 (saga), 而后逐一执行每个子事务, 一旦其中一环出现了错误, 经过补偿机制, 一一回滚以前已经执行的事务
$$
T1 T2 T3...Tj...Tn\
transaction\
C1 C2 C3...Cj...Cn \
compensating transaction
$$
整个流程有如下状况：

所有成功

$$
T1 → T2 → T3 →...→...→ Tn
$$

中途失败后回滚

$$
T1 → T2 → T3 →...→...→ Tj → Cj →...→ C3 → C2 → C1
$$

注意点:

Tj 和 Cj 是幂等的
若是 Cj 执行不成功就须要人工介入
Tj-Cj 的结果应和 Cj - Tj 的执行结果相同

例子

假设一我的须要进行如上的飞机票预订, 订票系统须要向四个航空公司发出订票请求

若是其中任何一个环节出现了问题, 就经过补偿机制, 将以前预订的票逐一退订

与TCC的比较

不强制参与者实现try接口, 只须要能够commit和rollback
不须要占有预留资源
理想状况下, 只须要向每一个参与者发送1次请求 (TCC须要2次)