分布式基础-分布式事务

没有数据库前,数据如果是文件方式存储在磁盘中,那么如果写入的过程中,可能写入过程中出差;或者因为我们程序挂掉原因,导致数据可能写了一半,如果多个应用程序同时在写程序的话,那问题就更加复杂。

数据库发明，特别是事务概念，解决了这个问题，事务将多个读写操作看成一个整体，要么成功要么失败，对于应用程序来说，简化了我们的操作，失败的时候，我们知道数据是干净的，不存在乱的问题，可以放心地重试。说实话，事务涉及的东西挺多的，只能尽力去按照学习的内容梳理下。

一 事务

事务除了原子特性，还有一致性，隔离性，持久性，这四个特性。这就是耳熟能详的 ACID。A 代表原子性 Atomicity，C 代表一致性（Consistency), I 代表隔离性（Isolation）与 D 持久性（Durability）。

原子性，记得学习化学的时候， 学过”分子是保持物质化学性质的一种微粒，而原子是化学变化中最小的微粒”从这个角度来说，原子在化学变化中是不可分的。利用这个不可分的特性，来表示事务要么全部成功，要么全部失败，不存在中间状态，这样数据就很干净，非黑即白，不存在灰色地带；

一致性，一致性理解起来是有点别扭，数据满足特定的预定状态，经过事务之后仍然满足这些事务的状态约束。

隔离性，多个数据库的客户端在同时操作的时候，相互隔离，互不影响，完全不影响比较难，多个事务共同执行的时候，可能会出现脏读，不可重复读，幻读的问题。为解决这些问题，隔离性也是分级别的，读未提交，读已提交，可重复读，串行化。隔离性从前到后越来越严格，性能也越来越差。

读未提交，一个事务没提交时，它的变更就被其他的事务看到，那么从这个角度来说就有影响了，因为没提交的事务，如果最后事务回滚了，那就读到脏数据了；
读提交，是一个事务提交之后，别的事务才可以看到，这样就不会存在读到脏数据了；
可重复读，是指一个事务执行过程中看到的数据，总跟这个事务启动时看到数据一致，读提交虽然保证了事务提交之后才可以看到，但是在另外一个事务中随着时间的推移，我们看到的数据可能是不同的；而可重复读保障了在一个事务中看到的数据是相同的，可以解决幻读的其他问题。 串行化，串行化可以解决一切事务问题，因为所有的事务都是排序的了，所以不会有冲突。

持久性，一旦事务提交成功，即使存在硬件故障或数据库崩溃，事务对数据库的数据更改影响是持久的。

二 分布式事务

对于分布式系统来说，事务变的更加复杂，分布式事务经常用来解决的是多个系统操作的时候的事务问题。最常用举例的是电子商务上，我们购买东西，需要建立一个订单，并且需要扣减库存，我们需要保障两个系统都成功，才可以给用户返回成功。对订单系统来说是一个事务，对库存系统来说，又是另外一个事务。在这里分布式事务，要把订单系统的事务和库存系统事务看成一个事务，要么一起成功，要么一起失败。

实现分布式事务有三种基本方法：

• XA 二段式提交
• 三阶段提交
• 基于消息的最终一致性方法。

我们想下，如果我们要执行分布式事务，需要多个系统事务都执行成功，如果我们什么都不管，先发 A 系统，再发 B 系统，如果发送 A 系统后，执行事务失败的话直接返回失败，那么如果 A 系统事务执行成功；再发 B 系统的时候，如果 B 系统事务成功很容易，如果 B 系统执行事务失败，我们又如何对 A 系统进行回滚操作那？如果让程序来进行处理，也不是不可能，不过就会很复杂，我们需要针对不同的情况来执行不同操作。

我们如果把这两个执行事务的系统看成一个系统，这整个系统支持分布式事务，多个系统如果要整体对外一致的表现，需要一个协调者，这个系统者有点像用户代理，通过这个协调者来保障，那是不是还按照刚才的步骤来，刚才的步骤有很大的失败概率。比如订单系统很可能成功的，但是库存系统因为库存的原因有一定的几率会失败，如果我们在真正提交之前，我们先进行问询，在 XA 二阶段中被称为问询阶段。

XA 是一个分布式事务协议，规定了事务管理器和资源管理器接口。其实事务管理器就是我们说的协调者，负责问询各节点事务，向各个节点发起事务提交； 资源管理接口，是分布式事务参与者，通常由数据库实现。

二阶段提交协议（The two-phase commit protocol 2PC）像我们所说的一样，先要进行问询（投票）和提交（commit）两个阶段。

协调者会向事务参与者发起执行操作的 CanCommit 请求，等待参与者的响应。参与者收到请求后，会执行请求中的事务操作，记录日志信息但是不提交，待参与者执行成功，则向协调者发送 Yes，表示准许执行；如果不成功，则返回 No 消息，则表示终止操作。

当所有的参与者都返回结果后，协调者进入第二阶段，如果都返回 yes，则向参与者发送 DoCommit 消息，参与者完成剩下的操作，并释放资源，向协调者返回”HaveCommited”消息； 如果有一个参与者返回 No，则向所有参与者发送 DoAbort 消息，所有的参与者会做回滚操作，参与者向协调者发送”HaveCommited” 消息。

二阶段提交顺利的话，看起来很美好，但是实际上有不少问题：

三阶段提交是为了解决二阶段的问题：

这个阶段和 2PC 的第一个阶段一样类似，判断是否可以执行事务，然后返回是否可以顺利执行事务。

如果都回复 Yes，则协调者进行预提交：

如果协调者从参与者都收到 ACK 消息：

如果协调者没有收全所有参与者的成功返回，会执行中断事务操作。

2.3 利用分布式消息实现最终一致性

有些场合，数据一致性要求不一定要求这么严格，无论是两阶段提交还是三阶段提交都无法解决锁资源和数据最终不一致问题。在只要求最终一致性场合，可以通过分布式消息来实现最终一致性。

其实我理解因为通过了分布式消息，一般会引入分布式消息队列，这样只要第一个系统得事务消息被持久了之后，后续的系统就算失败了，还可以继续重试；这样异步方式实现最终一致性也有缺点，就是返回了不代表整个事务都完成了，多个子系统什么时候一定可以完成事务是不确定的，当然由于是异步处理的，所以系统的性能是最好的。

我们说的数据一致性要求不是这么严格，有个 BASE 理论专门来说这个事情。基本可用（Basically Avaiable） 即出现故障时候，可以断臂求生，其他功能还可以用。 （Soft state） 柔状态，准许系统处于一个中间状态，等待最终同步为最终状态。 （Eventual Consistency） 最终一致性事务在操作过程中数据存在同步延迟，但是最终状态是一致的。

三 诗词欣赏

&#xA0;&#x300A;&#x68A6;&#x6E38;&#x5929;&#x59E5;&#x541F;&#x7559;&#x522B;&#x300B;<br>&#xA0;&#xA0;&#xA0;&#xA0;&#x674E;&#x767D;<br><br>&#x6D77;&#x5BA2;&#x8C08;&#x701B;&#x6D32;&#xFF0C;&#x70DF;&#x6D9B;&#x5FAE;&#x832B;&#x4FE1;&#x96BE;&#x6C42;&#x3002;<br>&#x8D8A;&#x4EBA;&#x8BED;&#x5929;&#x59E5;&#xFF0C;&#x4E91;&#x971E;&#x660E;&#x706D;&#x6216;&#x53EF;&#x7779;&#x3002;<br><br>&#x5929;&#x59E5;&#x8FDE;&#x5929;&#x5411;&#x5929;&#x6A2A;&#xFF0C;&#x52BF;&#x62D4;&#x4E94;&#x5CB3;&#x63A9;&#x8D64;&#x57CE;&#x3002;<br>&#x5929;&#x53F0;&#x4E00;&#x4E07;&#x516B;&#x5343;&#x4E08;&#xFF0C;&#x5BF9;&#x6B64;&#x6B32;&#x5012;&#x4E1C;&#x5357;&#x503E;&#x3002;<br>&#x6211;&#x6B32;&#x56E0;&#x4E4B;&#x68A6;&#x5434;&#x8D8A;&#xFF0C;&#x4E00;&#x591C;&#x98DE;&#x5EA6;&#x955C;&#x6E56;&#x6708;&#x3002;<br>&#x6E56;&#x6708;&#x7167;&#x6211;&#x5F71;&#xFF0C;&#x9001;&#x6211;&#x81F3;&#x5261;&#x6EAA;&#x3002;<br>&#x8C22;&#x516C;&#x5BBF;&#x5904;&#x4ECA;&#x5C1A;&#x5728;&#xFF0C;&#x6E0C;&#x6C34;&#x8361;&#x6F3E;&#x6E05;&#x733F;&#x557C;&#x3002;<br>&#x811A;&#x8457;&#x8C22;&#x516C;&#x5C50;&#xFF0C;&#x8EAB;&#x767B;&#x9752;&#x4E91;&#x68AF;&#x3002;<br>&#x534A;&#x58C1;&#x89C1;&#x6D77;&#x65E5;&#xFF0C;&#x7A7A;&#x4E2D;&#x95FB;&#x5929;&#x9E21;&#x3002;<br>&#x5343;&#x5CA9;&#x4E07;&#x8F6C;&#x8DEF;&#x4E0D;&#x5B9A;&#xFF0C;&#x8FF7;&#x82B1;&#x501A;&#x77F3;&#x5FFD;&#x5DF2;&#x669D;&#x3002;<br>&#x718A;&#x5486;&#x9F99;&#x541F;&#x6BB7;&#x5CA9;&#x6CC9;&#xFF0C;&#x6817;&#x6DF1;&#x6797;&#x516E;&#x60CA;&#x5C42;&#x5DC5;&#x3002;<br>&#x4E91;&#x9752;&#x9752;&#x516E;&#x6B32;&#x96E8;&#xFF0C;&#x6C34;&#x6FB9;&#x6FB9;&#x516E;&#x751F;&#x70DF;&#x3002;<br>&#x5217;&#x7F3A;&#x9739;&#x96F3;&#xFF0C;&#x4E18;&#x5CE6;&#x5D29;&#x6467;&#x3002;&#x6D1E;&#x5929;&#x77F3;&#x6249;&#xFF0C;&#x8A07;&#x7136;&#x4E2D;&#x5F00;&#x3002;<br>&#x9752;&#x51A5;&#x6D69;&#x8361;&#x4E0D;&#x89C1;&#x5E95;&#xFF0C;&#x65E5;&#x6708;&#x7167;&#x8000;&#x91D1;&#x94F6;&#x53F0;&#x3002;<br>&#x9713;&#x4E3A;&#x8863;&#x516E;&#x98CE;&#x4E3A;&#x9A6C;&#xFF0C;&#x4E91;&#x4E4B;&#x541B;&#x516E;&#x7EB7;&#x7EB7;&#x800C;&#x6765;&#x4E0B;&#x3002;<br>&#x864E;&#x9F13;&#x745F;&#x516E;&#x9E3E;&#x56DE;&#x8F66;&#xFF0C;&#x4ED9;&#x4E4B;&#x4EBA;&#x516E;&#x5217;&#x5982;&#x9EBB;&#x3002;<br>&#x5FFD;&#x9B42;&#x60B8;&#x4EE5;&#x9B44;&#x52A8;&#xFF0C;&#x604D;&#x60CA;&#x8D77;&#x800C;&#x957F;&#x55DF;&#x3002;<br>&#x60DF;&#x89C9;&#x65F6;&#x4E4B;&#x6795;&#x5E2D;&#xFF0C;&#x5931;&#x5411;&#x6765;&#x4E4B;&#x70DF;&#x971E;&#x3002;<br>&#x4E16;&#x95F4;&#x884C;&#x4E50;&#x4EA6;&#x5982;&#x6B64;&#xFF0C;&#x53E4;&#x6765;&#x4E07;&#x4E8B;&#x4E1C;&#x6D41;&#x6C34;&#x3002;<br>&#x522B;&#x541B;&#x53BB;&#x516E;&#x4F55;&#x65F6;&#x8FD8;&#xFF0C;&#x4E14;&#x653E;&#x767D;&#x9E7F;&#x9752;&#x5D16;&#x95F4;&#xFF0C;<br>&#x987B;&#x884C;&#x5373;&#x9A91;&#x8BBF;&#x540D;&#x5C71;&#x3002;&#x5B89;&#x80FD;&#x6467;&#x7709;&#x6298;&#x8170;&#x4E8B;&#x6743;&#x8D35;&#xFF0C;<br>&#x4F7F;&#x6211;&#x4E0D;&#x5F97;&#x5F00;&#x5FC3;&#x989C;&#x3002;

Original: https://www.cnblogs.com/seaspring/p/13643011.html
Author: XGogo
Title: 分布式基础-分布式事务