单体数据库不触及网络交互，所以在多表之间完成事务是比较复杂的，这种事务称之为本地事务。
但是单体数据库的功用到达瓶颈的时分，就需求分库，就会出现跨库(数据库实例)的事务需求；随着企业运用的规模越来越大，企业会进一步停止效劳化改造，以满足业务增长的需求；以后微效劳架构越来越盛行，跨效劳的事务场景也会越来越多。
这些都属于散布式事务。散布式事务是指是指事务的发起者、参与者、数据资源效劳器以及事务管理器辨别位于散布式系统的不同节点之上。
概括起来，散布式事务有三种场景：
跨数据库散布式事务
跨效劳散布式事务
混合式散布式事务
本文将引见散布式事务常见的处置方案：
2PC
3PC
TCC
Saga事务
基于本地音讯表机制
基于事务音讯机制
最大努力通知机制
常见处置方案散布式事务是由多个本地事务组成的，散布式事务跨越了多设备，之间又阅历的复杂的网络，可想而知想要完成严厉的事务路途阻且长。
2PC二阶段提交(Two-phase Commit，简称2PC)，是指为了使基于散布式系统架构下的一切节点在停止事务提交时保持分歧性而设计的一种算法(Algorithm)。
全体分为两个阶段，如图所示。
2PC的优点是能应用参与者（RM）本身的功用停止本地事务的提交和回滚，对业务逻辑零侵入（相对TCC处置方案）。
但2PC也存在三大缺陷：同步阻塞、单点缺点和数据不分歧成绩。
同步阻塞
由于参与者（RM）在执行操作时都是同步阻塞的，所以在2PC进程中其他节点拜访加锁资源不得不处于阻塞形状。
单点缺点
协调者（TM）是单点，一旦协调者发作缺点，参与者会不断阻塞。假设是某个热点资源阻塞，能够会招致整个系统的雪崩。
数据不分歧成绩
在第二阶段中，由于网络缘由招致部分参与者（RM）没有接纳到协调者（TM）的信息，或许部分参与者停止提交/回滚操作时，发作异常。这都会招致数据的不分歧性成绩。
2PC的优化Percolator是Google的上一代散布式事务处置方案，构建在BigTable之上，在Google外部用于网页索引更新的业务，原始的论文见于参考文档4。
TiDB的事务模型沿用了Percolator的事务模型，之后解说散布式数据库相关博客停止解说。
3PC3PC相对2PC添加了三阶段形式以及超机遇制。
超机遇制：第三阶段中，当参与者长时间没有失掉协调者的照应，在默许状况下，参与者会自动将超时的事务停止提交（即使是协调者发送的能够是rollback命令，这里就形成了数据的不分歧）。处置2PC同步阻塞的状况.
同时3PC添加的第一阶段的讯问通知，降低2PC中的数据不分歧成绩的概率。
但2PC中的单点缺点成绩，3PC并没有处置。
3PC的三个阶段，如图所示：
第一阶段，CanCommit
第二阶段，PreCommit
第三阶段，DoCommit
2PC还是3PC都是协议，是一种指点思想，与项目中真正的落中央案还是有差别的。
但2PC和3PC关于大型散布式系统很少会运用，由于在事务处置进程中，协调者需求同时衔接多个数据库（RM）。
通常微效劳都是衔接各自范围的数据库，微效劳想要修正另一个范围的数据，都是要经过RPC接口来完成的，并不会少数据源拜访。假设存在过多协调者停止少数据源的链接，势必会添加效劳管理的难度并能够招致数据的紊乱。
TCC不管是2PC还是3PC都是依赖于数据库的事务提交和回滚。
但有时一些业务不只仅触及到数据库，例如发送一条短信、上传一张图片等业务层的逻辑。
所以事务的提交和回滚就得提升到业务层面而不是数据库层面了，而TCC就是一种业务层面的两阶段提交。
TCC (Try、Commit、Cancel) 是一种补偿型事务。该模型要求运用的每个效劳提供try、confirm、cancel三个接口，中心思想是首先对资源的停止预留评价，假设事务可以提交，则完成对预留资源确实认；假设事务要回滚，则释放预留的资源。
TCC其本质是一个运用层面上的2PC，异样分为两个阶段，如下图所示：
比如：一个扣款效劳运用TCC的话，需求写Try办法，用来扣款资金；还需求一个Confirm办法来执行真正的扣款；最后还需求提供Cancel办法用于停止扣款操作的回滚。
可以看到本来的一个办法，需求收缩成三个办法，所以说TCC对业务有很大的侵入。
虽说对业务有侵入，但是TCC没有资源的阻塞，每一个办法都是直接提交事务的，假设出错是经过业务层面的Cancel来停止补偿，所以TCC属于补偿型事务。
关于2PC中出现单点缺点成绩或超时成绩，TCC的处置方案是不停重试：不停地重试没有收到照应的Confirm/Cancel接口直到成功为止，假设重试策略失败就经过记载和报警停止人工介入。
但这种重试机制，形成了TCC的幂等成绩与空回滚成绩。
TCC需求留意的成绩
幂等成绩
由于有重调机制，因此关于Try、Confirm、Cancel三个办法都需求幂等完成，避免重复执行产生错误。
空回滚成绩
参与者（RM）的Try接口照应由于网络成绩没有让协调者（TM）成功接纳到，此时协调者（TM）就会收回Cancel命令。那么Cancel接口就需求在未执行Try的状况下能正常的Cancel。
悬挂成绩
(责任编辑：admin)