阿里云大学-Java学习路线观看笔记系列09-数据库开发-4
Table of Contents
1. 什么是分布式事务
2. 分布式事务产生的原因
2.1. 数据库分库分表
2.2. 业务服务化
3. 分布式事务原理简介
3.1. ACID
3.2. 2PC
3.3. 2PC应用之XA
3.4. 2PC应用之TCC
4. 柔性事务(BASE理论)
5. 柔性事务的分类
5.1. 两阶段型
5.2. 补偿型
5.3. 异步确保型
5.4. 最大努力通知型
1 什么是分布式事务
分布式事务就是指事务的资源分别位于不同的分布式系统的不同节点之上的事务；
2 分布式事务产生的原因
2.1 数据库分库分表
在单库单表场景下，当业务数据量达到单库单表的极限时，就需要考虑分库分表，将之前的单库单表拆分成多库多表；
分库分表之后，原来在单个数据库上的事务操作，可能就变成跨多个数据库的操作，此时就需要使用分布式事务；
2.2 业务服务化
业务服务化即业务按照面向服务（SOA）的架构拆分整个网站系统；
比如互联网金融网站SOA拆分，分离出交易系统、账务系统、清算系统等，交易系统负责交易管理和记录交易明细，账务系统负责维护用户余额，所有的业务操作都以服务的方式对外发布；
一笔金融交易操作需要同时记录交易明细和完成用户余额的转账，此时需要分别调用交易系统的交易明细服务和账务系统的用户余额服务，这种跨应用、跨服务的操作需要使用分布式事务才能保证金融数据的一致性；
3 分布式事务原理简介
3.1 ACID
1、原子性（Atomicity）
整个事务中的所有操作，要么都成功，要么都失败，不可能部分操作成功部分操作失败；
2、一致性（Consistency）
事务必须使数据库的数据从一个一致性状态变换到另外一个一致性状态。
3、隔离性（Isolation）
事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
4、持久性（Durability）
在事务成功以后，该事务对数据库所做的更改应当持久的保存在数据库中；
3.2 2PC
两阶段提交协议（Two Phase Commitment Protocol）是分布式事务的基础协议。
在此协议中，一个事务协调器（TM, transaction manager）协调多个资源管理器（RM, resource manager）的活动；在一阶段所有资源管理器（RM）向事务管理器（TM）汇报自身活动状态，在第二阶段事务管理器（TM）根据各资源管理器（RM）汇报的状态，来决定各RM是执行提交操作还是回滚操作；
应用程序向事务管理器（TM）提交请求，发起方分布式事务；
一阶段，事务管理器（TM）联络所有资源管理器（RM），通知它们执行准备操作；
资源管理器（RM）返回准备成功，或者失败的消息给TM（响应超时算作失败）；
二阶段，如果所有RM均准备成功，TM会通知所有RM执行提交；如果任一RM准备失败，TM会通知所有RM回滚；
通过事务管理器2阶段协调资源管理器，使所有资源管理器的状态最终都是一致的，要么全部提交，要么全部回滚。
3.3 2PC应用之XA
XA是X/Open组织提出的，定义了事务管理器与资源管理器之间通信的接口协议；XA协议由数据库实现，目前支持XA协议的数据库有Oracle、MySql、BD2等；
XA定义了一系列的接口：
xa_start: 启动XA事务
xa_end: 结束XA事务
xa_prepare: 准备阶段，XA事务预提交
xa_commit：提交XA事务
xa_rollback: 回滚XA事务
一个数据库实现XA协议之后，它就可以作为作为一个资源管理器参与到分布式事务中;
在一阶段，事务管理器协调所有数据库执行XA事务（xa_start、用户SQL、xa_end），并完成XA事务预提交（xa_prepare）；
在二阶段，如果所有数据库上XA事务预提交均成功，那么事务管理器协调所有数据库提交XA事务（xa_commit）；如果任一数据库上XA是我预提交失败，那么事务管理器会协调所有数据组回滚XA事务（xa_rollback）;
3.4 2PC应用之TCC
TCC是Try、Confirm、Cancel 3个操作的缩写；
Try操作对应2PC的一阶段Prepare，Confirm对应2PC的二阶段commit，Cancel对应2PC的二阶段rollback；
这3个操作均有用户编码实现；
TCC三个操作描述：
Try: 检测、预留资源;
Confirm: 业务系统执行提交；默认Confirm阶段是不会出错的，只要TRY成功，CONFIRM一定成功；
Cancel: 业务取消，预留资源释放;
用户通编码实现TCC并发布成服务，这个TCC服务就可以作为资源参与到分布式事务中；事务管理器分2阶段协调所有的TCC资源，使得所有TCC资源状态最终都是一致，要么全部提交，要么全部回滚；
TCC自编码的特性决定TCC资源管理器可以跨DB、跨应用实现资源管理，将对不同的DB访问、不同的业务操作通过编码方式转换一个原子操作，解决了复杂业务场景下的事务问题；
同时TCC的每一个操作对于DB来讲都是一个本地DB事务，操作结束则本地DB事务结束，数据库的资源也就被释放；这就规避了数据库层面的2PC对资源占用导致的性能低下问题；
4 柔性事务(BASE理论)
单数据库事务完全遵循ACID规范，属于刚性事务，分布式事务要完全遵循ACID规范比较困难, 分布式事务属于柔性事务，满足BASE理论；
BASE描述：BA（Basic Availability 基本业务可用性）、S（Soft state 柔性状态）、E（Eventual consistency 最终一致性）；
柔性事务对ACID的支持：
原子性：严格遵循；
一致性：事务完成后的一致性严格遵循，事务中的一致性可适当放宽；
隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽；
持久性：严格遵循；
为了可用性、性能的需要，柔性事务降低了一致性(C)与隔离性(I) 的要求，即“基本可用，最终一致”；
5 柔性事务的分类
柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型；
5.1 两阶段型
就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS，这是分布式环境下事务处理的典型模式。
5.2 补偿型
TCC型事务（Try/Confirm/Cancel）可以归为补偿型；TCC思路是:尽早释放锁；在Try成功的情况下，如果事务要回滚，Cancel将作为一个补偿机制，回滚Try操作；
TCC各操作事务本地化，且尽早提交 (放弃两阶段约束)；当全局事务要求回滚时，通过另一个本地事务实现“补偿”行为；
TCC是将资源层的两阶段提交协议转换到业务层，成为业务模型中的一部分；
5.3 异步确保型
将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用；比如消息事务机制；
5.4 最大努力通知型
通过通知服务器(消息通知)进行，允许失败，有补充机制；
全文完。
如果觉得不错，就随手点个「在看」吧。