事务

事务（Transaction），一般是指要做的或所做的工作。 在核算机术语中是指拜访并或许更新数据库中各种数据项的一个程序履行单元(unit)。事务一般由高级数据库操纵言语或编程言语（如SQL，C++或Java）书写的用户程序的履行所引起，并用形如begin transaction和end transaction句子（或函数调用）来界定。事务由事务开端(begin transaction)和事务完毕(end transaction)之间履行的整体操作组成。

核算机术语中的事务一般便是指数据库事务。简单来说便是一个大活动由多个小活动组成，这些小活动要么 全部 成功，要么 全不 成功。 经过事务的特性咱们可以愈加知道这一点。

事务特性

事务应该具有4个特点：原子性、一致性、阻隔性、耐久性。这四个特点一般称为 ACID特性。

  • 原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。
  • 一致性（consistency）。事务有必要是使数据库从一个一致性状况变到另一个一致性状况。一致性与原子性是密切相关的。
  • 阻隔性（isolation）。一个事务的履行不能被其他事务搅扰。即一个事务内部的操作及运用的数据对并发的其他事务是阻隔的，并发履行的各个事务之间不能互相搅扰。
  • 耐久性（durability）。耐久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改动就应该是永久性的。接下来的其他操作或毛病不应该对其有任何影响。

举个例子理解下。

begin transaction
1. 增加用户张三
2. 增加张三的权限
end transaction

创建用户张三是所要做的工作，增加用户张三 和 增加张三的权限 是两个小活动。这两个小活动全部成功履行，那么创建用户张三这件工作也就履行成功，假如 增加用户张三 和 增加张三的权限 这两个小活动中有一个不成功，那么创建用户张三这件工作也就失利了，这两个小活动也就要都失利。

分布式事务

互联网的高速发展，运用复杂程度越来越高，规划越来越大，前期的单体运用现已演化成分布式运用。多个独立布置在不同核算机上的服务经过网络来共同完结一项活动。刚刚说的一个个 ”小活动“，也就分布在了不同的核算机之上，经过网络协作共同完结一件工作，这便是 分布式事务 了。

begin transaction
1. 增加用户张三
2. 增加张三的权限
end transaction

现在咱们把用户服务和权限服务布置到了不同的核算机上，经过网络调用来协作，工作是不是变得不一样了呢？

假如增加用户张三成功，增加张三的权限因为网络原因没有即便回来或许回来过错（其实是数据刺进成功），这时事务回滚。终究成果是用户未增加，可是权限增加成功，这并没有达到咱们所预期的作用。所以分布式状况下事务的处理和单体运用的本地事务处理方法有所区别，分布式事务需求有对应的处理方案来达到咱们所预期要的作用。

XA协议

XA协议 由Tuxedo首先提出的，并交给X/Open安排，作为资源办理器（数据库）与事务办理器的接口规范。

Oracle、Informix、DB2和Sybase等各大数据库厂家都供给对XA的支撑。XA协议选用两阶段提交方法来办理分布式事务。

XA接口供给资源办理器与事务办理器之间进行通信的规范接口。

XA中有这几个概念

  • 事务办理器 (Transaction Manager)：简称TM，是一个体系组件，担任协谐和办理事务的履行。为体系的可靠运行供给了重要保障。一般包括在运用程序中。
  • 资源办理器 (Resource Manager)：简称RM，是担任办理分布式事务中各个本地资源的组件。资源办理器由数据库完结，例如Oracle、DB2等数据库都完结了XA规范的接口。

当然还有应该有一个概念便是咱们编写的运用程序(Application Program)，简称AP。

TM，RM，AP共同组成了X/Open安排定义的一套分布式事务的规范 DTP模型 。

浅谈分布式事务

2PC

XA协议选用两阶段提交方法来办理分布式事务，简称 2PC，在此协议中，一个或多个资源办理器的活动均由一个称为事务和谐器的单独软件组件来控制。2PC的过程如下：

  1. 运用程序调用事务和谐器中的提交方法。
  2. 事务和谐器将联络事务中触及的每个资源办理器，并通知它们准备提交事务（这是第一阶段的开端）。
  3. 为了以肯定的方法呼应准备阶段，资源办理器有必要将自己置于以下状况：确保能在被要求提交事务时提交事务，或在被要求回滚事务时回滚事务。大多数资源办理器会将包括其方案更改的日记文件（或等效文件）写入耐久存储区中。假如资源办理器无法准备事务，它会以一个否定呼应来回应事务和谐器。
  4. 事务和谐器搜集来自资源办理器的一切呼应。
  5. 在第二阶段，事务和谐器将事务的成果通知给每个资源办理器。假如任一资源办理器做出否定呼应，则事务和谐器会将一个回滚指令发送给事务中触及的一切资源办理器。假如资源办理器都做出肯定呼应，则事务和谐器会指示一切的资源办理器提交事务。一旦通知资源办理器提交，此后的事务就不能失利了。经过以肯定的方法响 应第一阶段，每个资源办理器均已确保，假如以后通知它提交事务，则事务不会失利。

Mysql中的XA协议完结

以Mysql（InnoDB引擎）对XA协议的完结咱们来看看什么是两阶段提交。

XA START 'createuser';
-- SQL句子
-- SQL句子
-- SQL句子
XA END 'createuser';
XA PREPARE 'createuser';
XA COMMIT 'createuser';
  • XA START ：敞开一个XA事务，并把它置于 ACTIVE 状况，可以指定跟一个 XID，一般由 TM 生成。
  • XA END ：完毕一个XA事务，将事务置于 IDLE 状况。
  • XA PREPARE ：准备一个XA事务，把事务放入 PREPARED 状况，这时 XA RECOVER 指令可以列出一切处于 PREPARED 状况的XA事务。
  • XA COMMIT / XA ROLLBACK ：提交/回滚 一个XA事务。

可以看到跟咱们的正常 Mysql 事务仅仅只是多了一个 PREPARE 准备阶段。2PC 中 PREPARE 便是第一阶段，COMMIT 便是第二阶段。

试想一下分布式事务状况下，假如运用一阶段事务，同时提交多个事务，假如一个事务 COMMIT 成功，一个事务 COMMIT 失利，那么事务的特性将得不到确保。2PC 加了一个 准备 阶段，一切事务都准备完结后，就差最后 COMMIT 这一步，将防止这种问题的呈现。

浅谈分布式事务

XA缺陷

哦豁，乍一看确实不错，可是深化思考下 2PC 有没有什么问题呢？

2PC 是一个 强一致性 的同步阻塞协议，需求确定事务履行过程中的资源，也便是所谓的刚性事务。这也就导致了一些缺陷的呈现。

  1. 在高并发场景下性能并非很好。合适履行比较快比较短的事务。
  2. 或许会形成死锁。确定数据，假如后续没有提交事务的指令或许回滚事务的指令(比方TM宕机，或网络问题等)，数据库就会一直确定数据，形成数据库死锁的问题。

3PC

三阶段提交便是针对二阶段提交缺陷的改善版本，三阶段提交协议在和谐者和参与者都引入了超时机制。

3PC 将 2PC 的准备阶段拆分成了两个过程 CanCommit 和 PreCommit。

3PC 履行过程

  • CanCommit：和 2PC 的准备阶段很像，问询是否可以履行事务提交操作，各参与者根据本身状况回复预估值，假如预估自己可以正常履行事务就回来确定信息，并进入准备状况，不然回来否定信息。
  • PreCommit：和谐者根据第一阶段的问询成果采纳相应操作。假如一切参与者都回来确定信息，则和谐者会向一切参与者发送 pre commit 恳求。假如只有一个或多个参与者回来否定信息，或许和谐者等候超时，则会中止事务。
  • DoCommit：各参与者收到 do commit 恳求后，会正式履行事务提交操作，并在完结提交后释放占用资源。

浅谈分布式事务

三阶段引入超时机制处理了堵塞问题，但多了一次恳求，性能上根据不同场景或许会比二阶段还差，超时机制还或许会呈现幂等性问题形成数据不一致。

TCC

TCC 事务机制比较于 2PC、3PC，不会确定整个资源，而是经过引入补偿机制，将资源转换为事务逻辑方式，锁的粒度变小。

TCC 可以理解为在运用层面的 2PC。

TCC 完结分布式事务有三个过程，分别是：

  1. try：这个阶段对各个服务的资源做检测以及对资源进行确定或许预留。
  2. confirm：真实的履行事务逻辑，try 阶段现已做了查看。因此直接履行不做任何的查看，履行过程中会运用到 try 阶段预留的资源。需求考虑幂等性问题，失利后或许需求进行重试。
  3. cancel：try 履行失利会进入 cancel 阶段进行补偿。回滚操作，对 try 阶段运用的资源进行释放。需求考虑幂等性问题，失利后需求进行重试。

浅谈分布式事务

TCC优劣势

TCC 形式事务之间没有阻塞，性能比较 2PC 将会有所提升。

事务的胜败完全赖开发人员编写事务代码完结，所以编码的好坏直接影响 TCC 事务的履行。

confirm 和cancel 阶段的幂等性也需求着重关注，事务的一致性需求确保。

TCC 需求植入事务代码，并且这部分的代码很难复用，加大了开发难度和时间。

总结

并没有完美的处理方案，可以处理掉一切事务问题。在实际事务运用中，需求根据不同事务场景的特性来选择合适的分布式处理方案。