vlambda博客
学习文章列表

融合java面试19讲的內容，下边咱们聊一下分布式事务：

分布式事务就是指会牵涉到实际操作好几个数据库查询的事务管理,在分布式系统中，每个连接点中间在物理学上互不相关，根据互联网开展交流和融洽。XA 便是 X/Open DTP 界定的买卖中间件与数据库查询中间的接口规范（即接口函数），买卖中间件用它来通告数据库事务的逐渐、完毕及其递交、回滚等。XA 接口函数由数据库查询厂家给予。

二环节递交(Two-phaseCommit)就是指，在互联网及其数据库查询行业内，为了更好地使根据分布式系统构架下的全部连接点在开展事务管理递交时维持一致性而制定的一种优化算法(Algorithm)。通常，二环节递交也被称作是一种协议书(Protocol))。在分布式系统中，每一个连接点尽管可以了解自身的实际操作时取得成功或是不成功，却没法了解别的结点的实际操作的完成或不成功。当一个事务管理超越好几个连接点时，为了更好地维持事务管理的 ACID 特点，必须引进一个做为协调者的模块来统一操控全部连接点(称之为参加者)的使用結果并最后标示这种连接点是不是要把实际操作結果开展真实的递交(例如将升级后的数据信息写进硬盘这些)。因而，二环节递交的优化算法构思可以归纳为：参加者将实际操作成功与失败通告协调者，再由协调者依据全部参加者的意见反馈情报信息决策各参加者是不是要递交实际操作或是中断实际操作。

1. 提前准备环节

事务管理协调者(事务管理工具)给每一个参加者(资源管理器)推送 Prepare 信息，每一个参加者要不立即回到不成功(如管理权限验证失败)，要不在当地实行事务管理，写当地的 redo 和 undo 日志，但不递交，抵达一种“万事俱备，只欠东风”的情况。

2. 递交环节

假如协调者收到了参加者的不成功信息或是请求超时，立即给每一个参加者推送回滚(Rollback)信息；不然，推送递交(Commit)信息；参加者依据协调者的命令实行递交或是回滚实际操作，释放出来全部事务管理处理方式中采用的锁資源。(留意:务必在最终环节释放出来锁資源)

3. 缺陷

同歩堵塞问题

1、实行环节中，全部参加连接点全是事务管理堵塞型的。

单点故障

2、因为协调者的必要性，一旦协调者产生常见故障。参加者会一直堵塞下来。

数据信息不一致（脑裂问题）

3、在二环节递交的环节二中，当协调者向参加者推送 commit 要求以后，发生了部分网络异常或是在推送 commit 要求全过程中协调者发生了常见故障，造成仅有一部分参加者接纳到了commit 要求。因此全部分布式系统便产生了数据信息部一致性的状况(脑裂现象)

二环节没法化解的问题（数据信息情况不确定性）

4、协调者再传出 commit 信息以后宕机，而唯一接受到这一条信息的参加者与此同时也宕机了。那麼即使协调者根据大选协议书造成了新的协调者，这条事务管理的模式也是不确定性的，没有人了解事务管理是不是被早已递交。

三环节递交（ Three-phase commit ），也叫三环节递交协议书（ Three-phase commitprotocol），是二环节递交（2PC）的优化版本号。与两环节递交不一样的是，三环节递交有两个修改点。

1、引进请求超时体制。与此同时在协调者和参加者里都引进请求超时体制。

2、在第一阶段和第二阶段中插进一个提前准备环节。确保了在最终递交环节以前各参加连接点的情况是一致的。换句话说，除开引进请求超时体制以外，3PC 把 2PC 的提前准备环节再度一分为二，那样三环节递交就会有 CanCommit、PreCommit、DoCommit 三个环节。

1. CanCommit 阶段

协调者向参加者推送 commit 要求，参加者假如能递交就回到 Yes 回应，不然回到 No 回应。

2. PreCommit 环节

协调者依据参加者的反映情形来选择是不是可以再次开展，有下列二种很有可能。倘若协调者从任何的参加者得到的意见反馈全是 Yes 回应，那麼便会实行事务管理的预实行倘若有一切一个参加者向协调者推送了 No 回应，或是等候请求超时以后，协调者也没有收到参加者的回应，那麼就实行事务管理的终断。

3. doCommit 环节

该阶段开展真实的事务管理递交，关键包括 1.融洽这推送递交要求 2.参加者递交事务管理 3.参加者回应意见反馈（事务管理递交完以后，向协调者推送 Ack 回应。）4.协调者明确进行事务管理。

1. 软性事务管理

在电子商务行业等互联网技术情景下，传统式的事务管理在数据库查询功能和解决工作能力上面显现出了短板。在分布式系统行业根据 CAP 基础理论及其 BASE 基础理论，有些人就指出了 软性事务管理 的定义。CAP（一致性、易用性、系统分区容忍性）基础理论大家都了解很多次了，这儿不会再描述。说一下 BASE 基础理论，它是在 CAP 理论的前提上的拓宽。包含 基本上可以用（Basically Available）、软性情况（Soft State）、最后一致性（Eventual Consistency）。通常所指的软性事务管理分成：两环节型、赔偿型、异步保证 型、较大勤奋通告型几类。

两环节型

1、便是分布式事务两环节递交，相匹配技术性上的 XA、JTA/JTS。这也是分布式系统条件下事务管理的典型性方式。

赔偿型

2、TCC 型事务管理（Try/Confirm/Cancel）可以归到赔偿型。

WS-BusinessActivity 给予了一种根据赔偿的 long-running 的事务管理实体模型。网络服务器 A 进行事务管理，网络服务器 B 参加事务管理，网络服务器 A 的事务管理假如实行成功，那麼事务管理 A 就优先递交，假如事务管理 B 也实行成功，则事务管理 B 也递交，全部事务管理即使进行。可是假如事务管理 B 实行不成功，事务管理 B 自身回滚，这时事务管理 A 早已被递交，因此必须运行一个赔偿实际操作，将早已递交的事务管理 A 实行的实际操作作反操作，修复到未实行前事务管理 A 的情况。那样的 SAGA 事务管理实体模型，是放弃了一定的防护性和一致性的，可是提升了 long-running 事务管理的易用性。

异步保证 型

3、根据将一系列同歩的事务管理实际操作变成根据信息实行的异步实际操作, 防止了分布式事务中的同歩堵塞实际操作的危害

较大勤奋通告型（多次试着）

4、这也是分布式事务中规定最少的一种, 还可以根据消息中间件完成, 与前边异步保证 型实际操作不一样的一点是, 在信息由 MQ Server 递送到顾客以后, 容许在做到较大重试频次以后一切正常完毕事务管理。

CAP 标准又被称为 CAP 定律，指的是在一个分布式系统中， Consistency（一致性）、 Availability（易用性）、Partition tolerance（系统分区容错性），三者不能得兼。

一致性（C）：

1. 在分布式系统中的全部备份数据，在同一时时刻刻是不是一样的值。（相当于全部连接点浏览同一份全新的信息团本）

易用性（A）：

2. 在群集中一部分连接点常见故障后，群集总体是不是还能回应手机客户端的读写能力要求。（对数据信息升级具有高可用性）

系统分区容忍性（P）：

3. 以预期效果来讲，系统分区等同于对通讯的时间规定。系统软件假如无法在期限内达到数据信息一致性，就代表着发生了系统分区的状况，务必就目前实际操作在 C 和 A 中间作出挑选 。

1.被cancel

2.communicate

3.insist