The Eight Fallacies of Distributed Computing by Peter Deutsch.
Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn’t change
- There is one administrator
- Transport cost is zero
- The network is homogeneous
1. 2PC
XA规范中定义的分布式事务模型包括四个组成部分:
- RM(Resource Manager,资源管理器),负责管理分布式系统中的部分数据资源,保障该部分数据的一致性,满足规范要求的数据管理系统均可作为RM参与分布式事务,最典型的应用是数据库,如MySQL、Oracle、SQLServer等均支持该规范
- TM(Transaction Manager,事务管理器),负责协调跨RM的全局事务的开启、提交和回滚
- AP(Application Program,应用程序),通过TM定义事务边界,执行全局事务
- CRM(Communication Resource Managers,通信管理器),负责全局事务过程中的跨节点通信
二阶段提交是一种强一致性的设计。设置一个中心的协调者(Coordinator,也称Transaction Manager,TM)与多个被调度的业务节点参与者(Participant,也称Resource Manager,RM)。
第一阶段(prepare):
- TM记录事务开始日志。
- 向所有RM发送Prepare消息,等待响应。
- 每个参与者都执行事务,记录Undo/Redo日志,向TM返回结果,RM并不提交事务。
- TM记录准备完成日志。
第二阶段(if commit):
- 当事务管理者(TM)确认所有参与者(RM)都ready后,TM记录事务提交日志。
- TM向所有RM发送commit命令。
- RM提交事务,向TM返回执行结果。
- TM记录事务结束日志。
第二阶段(if rollback):
- 当事务管理者(TM)确认有任一参与者(RM)失败或超时后,TM记录事务会滚日志。
- TM向所有RM发送rollback命令。
- RM回滚事务,向TM返回执行结果。
- TM记录事务结束日志。
2PC是对业务侵入性较小的强一致性的保证。对于MySQL,XA执行过程中,对对应的资源都要加锁,阻塞其他事务访问。并且TM很容易发生单点故障,此时便会存在数据不一致与不确定性。
2. Saga
Saga理论基础来源于Hector & Kenneth 在1987年发表的论⽂《SAGAS》。它把分布式事务看作一组本地分支事务构成的事务链,业务流程中每个参与者都提交本地事务。在执行链中任何一个失败,则反方向进行补偿操作。
补偿是子事务的提交,对线上其他事务可见,即:已经产生了影响,只能尽可能补偿。
Saga是满足了BASE,并不支持隔离性,可能会发生脏读脏写。吞吐量较高,一阶段提交本地事务,无锁,高性能。事件驱动架构,参与者可异步执行,而且子事务并不一定都需要是DB相关操作。
3. TCC
TCC(Try-Confirm-Cancel)理论源于 Pat Helland 在2007年发表的论文《Life beyond Distributed Transactions:an Apostate’s Opinion》。其将支持把自定义的分支事务纳入到全局事务的管理中
全局事务是由若干分支事务组成的,分支事务要满足2PC模型的要求。
将TM变成多节点,引入超时补偿的概念,并不会锁住所有资源。
- Try 阶段:完成所有业务检查,预留必须业务资源。
- Confirm 阶段:确认执行真正执行业务,只使用 Try 阶段预留的业务资源。一旦异常,发现事务提交标记,重试所有Confirm操作(需要保证幂等性)。
- Cancel 阶段:取消执行,释放 Try 阶段预留的业务资源。一旦异常,发现事务会滚标记,重试所有Cancel操作(需要保证幂等性)。
TCC满足BASE,相较于2PC,吞吐性、可用性更高。在业务层面保证隔离性。
4. AT
AT(Automatic Transaction)模式不依赖参与者对AX事务的支持。
在seata的实现中,Automatic (Branch) Transaction Mode对应AT模式,Manual (Branch) Transaction Mode对应TCC模式。
- 第一阶段(prepare):在本地事务中,一并提交业务数据更新和相应回滚日志记录。
- 第二阶段(commit):马上成功结束,自动 异步批量清理回滚日志。
- 第二阶段(rollback):通过回滚日志,自动 生成补偿操作,完成数据回滚。
隔离级别为RU,未提交的事务数据也会被其他事务读到。
*. Conclusion
XA | AT | TCC | Saga | 本地/事务消息方案 | |
---|---|---|---|---|---|
一致性 | 强一致 | 强一致 | 最终一致 | 最终一致 | 最终一致 |
隔离性 | 支持 | 读未提交 | 支持(通过业务层面在Try阶段的资源锁定实现隔离) | 不支持 | 不支持 |
性能 | 全局锁,性能差 | 吞吐量差,优于XA | Try操作使资源锁定可以尽早释放,系统吞吐量高 | 吞吐量高 | 吞吐量高 |
业务侵入 | 无侵入 | 无侵入 | 较高 | 较低 | 较低 |
优点 | 强一致性保证 业务无侵入 | 业务无侵入 适用于短事务 | 由业务层面来保证隔离性 性能相对较高,吞吐量高 | 性能相对较高,吞吐量高 对业务侵入较少 | 对业务侵入较少 通过消息中间件解耦,下游事务异步化 |
缺点 | 需要XA规范。存在同步阻塞、单点故障、数据不一致、不确定性等可用性问题 | 事务隔离级别为脏读 不适用于长事务 | 业务改造成本较高,业务需分拆为Try/Confirm/Cancel三个操作 引入中间态,业务复杂,不利于迭代维护。 | 不具备隔离性,易出现脏读,脏写问题,可能造成脏写无法回滚 | 不具备隔离性 不具备事务回滚,只能重试 |
适用业务 | 强一致性 短事务 一般可用性 | 强一致性 短事务 一般可用性 | 最终一致性 短事务 强可用性 | 最终一致性 长事务 强可用性 不要求隔离性 | |
备注 | 需要注意处理空回滚,重复提交,悬挂等异常情况 | 需要注意处理空补偿,重复提交,悬挂等异常情况 |