现今互联网界，分布式系统和微服务架构流行。一个简略操作，在服务端十分可能是由多个服务和数据库实例协同实现的。在互联网金融等一致性要求较高的场景下，多个独立操作之间的一致性问题显得分外辣手。随着业务的疾速倒退、业务复杂度越来越高，简直每个公司的零碎都会从单体走向分布式，特地是转向微服务架构，随之而来就必然遇到分布式事务这个难题。本文会介绍分布式事务的一些相干概念。
分布式事务的概念
数据库事务
数据库事务的目标
数据库事务（简称：事务）是数据库管理系统执行过程中的一个逻辑单位，由一个无限的数据库操作序列形成。数据库事务通常蕴含了一个序列的对数据库的读 / 写操作。蕴含有以下两个目标：
- 为数据库操作序列提供了一个从失败中复原到失常状态的办法，同时提供了数据库即便在异样状态下仍能放弃一致性的办法。
- 当多个应用程序在并发拜访数据库时，能够在这些应用程序之间提供一个隔离办法，以避免彼此的操作相互烦扰。
当事务被提交给了数据库管理系统（DBMS），则 DBMS 须要确保该事务中的所有操作都胜利实现且其后果被永恒保留在数据库中，如果事务中有的操作没有胜利实现，则事务中的所有操作都须要回滚，回到事务执行前的状态；同时，该事务对数据库或者其余事务的执行无影响，所有的事务都如同在独立的运行。
ACID 个性
数据库事务领有以下四个个性，习惯上被称之为 ACID 个性：
- 原子性(Atomicity): 事务中的所有操作作为一个整体像原子一样不可分割，要么全副胜利, 要么全副失败。
- 一致性(Consistency): 事务的执行后果必须使数据库从一个一致性状态到另一个一致性状态。一致性状态是指:1. 零碎的状态满足数据的完整性束缚(主码, 参照完整性,check 束缚等) 2. 零碎的状态反馈数据库本应形容的事实世界的实在状态, 比方转账前后两个账户的金额总和应该放弃不变。
- 隔离性(Isolation): 并发执行的事务不会相互影响, 其对数据库的影响和它们串行执行时一样。比方多个用户同时往一个账户转账, 最初账户的后果应该和他们按先后秩序转账的后果一样。
- 持久性(Durability): 事务一旦提交, 其对数据库的更新就是长久的。任何事务或系统故障都不会导致数据失落。
数据库的并发管制
影响数据库 ACID 实现的因素有两个：并发和系统故障，相应地，数据库系统通过并发控制技术和日志复原技术来实现数据库的 ACID 个性。
并发控制技术是实现事务隔离性以及不同隔离级别的要害, 实现形式有很多, 依照其对可能抵触的操作采取的不同策略能够分为乐观并发管制和乐观并发管制两大类。
- 乐观并发管制: 对于并发执行可能抵触的操作, 假设其不会真的抵触, 容许并发执行, 直到真正发生冲突时才去解决抵触, 比方让事务回滚。
- 乐观并发管制: 对于并发执行可能抵触的操作, 假设其必然发生冲突, 通过让事务期待 (锁) 或者停止 (工夫戳排序) 的形式使并行的操作串行执行。
其实现形式有多种：基于封闭的并发管制、基于工夫戳的并发管制、基于有效性查看的并发管制、基于快照隔离的并发管制.
数据库日志
数据库运行过程中可能会呈现故障, 这些故障包含事务故障和系统故障两大类
- 事务故障: 比方非法输出, 零碎呈现死锁, 导致事务无奈继续执行。
- 系统故障: 比方因为软件破绽或硬件谬误导致系统解体或停止。
这些故障可能会对事务和数据库状态造成毁坏, 因此必须提供一种技术来对各种故障进行复原, 保障数据库一致性, 事务的原子性以及持久性。数据库通常以日志的形式记录数据库的操作从而在故障时进行复原, 因此能够称之为日志复原技术。数据库日志蕴含 undo 和 redo 日志。
分布式事务场景
当咱们的单个数据库的性能产生瓶颈的时候，咱们可能会对数据库进行分区，这里所说的分区指的是物理分区，分区之后可能不同的库就处于不同的服务器上了，这个时候单个数据库的 ACID 曾经不能适应这种状况了，而在这种 ACID 的集群环境下，再想保障集群的 ACID 简直是很难达到，或者即便能达到那么效率和性能会大幅降落，最为要害的是再很难扩大新的分区了，这个时候如果再谋求集群的 ACID 会导致咱们的零碎变得很差，这时咱们就须要引入一个新的实践准则来适应这种集群的状况，就是 CAP 准则或者叫 CAP 定理？
CAP 定理
CAP 定理是由加州大学伯克利分校 Eric Brewer 传授提出来的，他指出 WEB 服务无奈同时满足一下 3 个属性：
- 一致性（Consistency）:（等同于所有节点拜访同一份最新的数据正本）
- 可用性（Availability）:（每次申请都能获取到非错的响应——然而不保障获取的数据为最新数据）
- 分区容错性（Partition tolerance）:（以实际效果而言，分区相当于对通信的时限要求。零碎如果不能在时限内达成数据一致性，就意味着产生了分区的状况，必须就以后操作在 C 和 A 之间做出抉择。）
依据定理，分布式系统只能满足三项中的两项而不可能满足全副三项。了解 CAP 实践的最简略形式是设想两个节点分处罚区两侧。容许至多一个节点更新状态会导致数据不统一，即丢失了 C 性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丢失了 A 性质。除非两个节点能够相互通信，能力既保证 C 又保障 A，这又会导致丢失 P 性质。
因而在进行分布式架构设计时，必须做出取舍。以后个别是通过分布式缓存中各节点的最终一致性来进步零碎的性能，通过应用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常应用相似 memcached 之类的 NOSQL 作为实现伎俩。尽管 memcached 也能够是分布式集群环境的，然而对于一份数据来说，它总是存储在某一台 memcached 服务器上。如果产生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可拜访。因为数据是存储在内存中的，重启服务器，将导致数据全副失落。当然也能够本人实现一套机制，用来在分布式 memcached 之间进行数据的同步和长久化，然而实现难度是十分大的。
分区容错性（Partition tolerance）
大多数分布式系统都散布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比方，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无奈通信。
图中，P1 和 P2 是两台跨区的服务器。P1 向 P2 发送一条音讯，P2 可能无奈收到。零碎设计的时候，必须思考到这种状况。一般来说，分区容错无奈防止，因而能够认为 CAP 的 P 总是成立。CAP 定理通知咱们，剩下的 C 和 A 无奈同时做到。
一致性（Consistency）
一致性意味着写操作之后的读操作，必须返回该值。举例来说，某条记录是 v1=1，用户向 P1 发动一个写操作，将其改为 v1=10, 接下来，用户的读操作就会失去 v1=10，这就叫一致性。
问题是，用户有可能向 P2 发动读操作，因为 P2 的值没有发生变化，因而返回的是 v0。P1 和 P2 读操作的后果不统一，这就不满足一致性了。
为了让 P2 也能变为 v1=10，就要在 P1 写操作的时候，让 P1 向 P2 发送一条音讯，要求 P2 也改成 v1=10。
可用性（Availability）
可用性是指只有收到用户的申请，服务器就必须给出回应。
用户能够抉择向 P1 或 P2 发动读操作。不论是哪台服务器，只有收到申请，就必须通知用户 v1 的值，否则就不满足可用性。
一致性和可用性的矛盾
一致性和可用性，为什么不可能同时成立？答案很简略，因为可能通信失败（即呈现分区容错）。
如果保障 P2 的一致性，那么 P1 必须在写操作时，锁定 P2 的读操作和写操作。只有数据同步后，能力从新凋谢读写。锁定期间，P2 不能读写，没有可用性。如果保障 P2 的可用性，那么势必不能锁定 P2，所以一致性不成立。综上所述，P2 无奈同时做到一致性和可用性。零碎设计时只能抉择一个指标。如果谋求一致性，那么无奈保障所有节点的可用性；如果谋求所有节点的可用性，那就没法做到一致性。
那么在什么场合，可用性高于一致性？举例来说，公布一张网页到 CDN，多个服务器有这张网页的正本。起初发现一个谬误，须要更新网页，这时只能每个服务器都更新一遍。一般来说，网页的更新不是特别强调一致性。短时期内，一些用户拿到老版本，另一些用户拿到新版本，问题不会特地大。当然，所有人最终都会看到新版本。所以，这个场合就是可用性高于一致性。
常见产品
Ereka->ereka 是 SpringCloud 系列用来做服务注册和发现的组件，作为服务发现的一个实现，在设计的时候就更思考了可用性，保障了 AP。
Zookeeper->Zookeeper 在实现上就义了可用性，保障了一致性（枯燥一致性）和分区容错性，也即：CP。所以这也是 SpringCloud 摈弃了 zookeeper 而抉择 Ereka 的起因。
Zookeeper 当 master 挂了，会在 30-120s 进行 leader 选举，这点相似于 redis 的哨兵机制，在选举期间 Zookeeper 是不可用的，这么长时间不能进行服务注册，是无法忍受的，别说 30s，5s 都不能忍耐。这时 Zookeeper 集群会瘫痪，这也是 Zookeeper 的 CP，放弃节点的一致性，就义了 A / 高可用。而 Eureka 不会，即便 Eureka 有局部挂掉，还有其余节点能够应用的，他们放弃平级的关系，只不过信息有可能不统一，这就是 AP，就义了 C / 一致性。
BASE 实践
如前文中说 CAP 定理是三个单词的缩写，BASE 也是一样，是由 Basically Available(根本可用)，Soft state（软状态）, 和 Eventually consistent（最终一致性）三个短语的缩写。
为什么要 BASE 实践
CAP 定理只能三选二，CAP 实践表明，对于一个分布式系统而言，它是无奈同时满足 Consistency(强一致性)、Availability(可用性) 和 Partition tolerance(分区容忍性) 这三个条件的，最多只能满足其中两个。
分区容错必须选，对于互联网来说，因为网络环境是不可信的，所以分区容错性（P）必须满足
为了用户体验，先选可用性。当初只能在一致性和可用性之间做抉择，大部分状况下，大家都会抉择就义一部分的一致性来保障可用性，因为你不返回给用户数据，这体验也太差了，宁肯拒绝服务也不能说能拜访却没有数据，当然，严格场景下，比方领取场景，强一致性是必须要满足，这另说。
然而放弃了一致性的零碎又失去了存在的意义，好了，咱们只能放弃一致性，然而咱们真这样做了，将一致性放弃了，当初这个零碎返回的数据你敢信吗？没有一致性，零碎中的数据也就从根本上变得不可信了，那这数据拿来有什么用，那这个零碎也就没有任何价值，基本没用。
如上所述，因为咱们三者都无奈摈弃，但 CAP 定理限度了咱们三者无奈同时满足，这种状况，咱们会抉择尽量凑近 CAP 定理，即尽量让 C、A、P 都满足，在此大势所趋下，呈现了 BASE 定理。
核心思想
强一致性（Strong consistency）无奈失去保障时（分区容错和可用性满足零碎），咱们能够依据业务本身的特点，采纳适当的形式来达到最终一致性（Eventual consistency）。
根本可用(Basically Available)
根本可用是绝对于失常的零碎来说的, 常见如下状况
响应工夫上的损失：失常状况下的搜索引擎 0.5 秒即返回给用户后果，而根本可用看的搜寻后果可能要 1 秒，2 秒甚至 3 秒。如下图中所示，原本用户能够从 redis 用 10ms 读取到数据，然而有些状况下为了保障一致性，须要从 MySql 破费 1s 读取数据，用户以更长的工夫代价拿到了数据。
性能上的损失：在一个电商网站上，失常状况下，用户能够顺利完成每一笔订单，然而到了促销工夫，可能为了应答并发，爱护购物零碎的稳定性，局部用户会被疏导到一个降级页面。
软状态
软状态是绝对原子性来说的
原子性（硬状态）-> 要求多个节点的数据正本都是统一的, 这是一种 ” 硬状态 ”。咱们在之前学习过硬状态，指的就是 ACID 的原子性。如下图所示，硬状态只有在订单状态、积分发送胜利、仓库出单胜利，即三者同时胜利的状况才算领取胜利。
软状态（弱状态）-> 容许零碎中的数据存在中间状态, 并认为该状态不影响零碎的整体可用性, 即容许零碎在多个不同节点的数据正本存在数据提早。软状态不须要完全符合 ACID 的原子性先把订单状态改成已领取胜利，而后通知用户曾经胜利了，剩下在异步发送 mq 音讯告诉积分服务和仓库服务，即便生产失败,MQ 音讯也会从新发送（重试）。
最终一致性(Eventually consistent)
弱一致性和强一致性绝对，零碎并不保障间断过程或者线程的拜访都会返回最新的更新过的值。零碎在数据写入胜利之后，不承诺立刻能够读到最新写入的值，也不会具体的承诺多久之后能够读到。但会 尽可能保障在某个工夫级别（比方秒级别）之后，能够让数据达到一致性状态。最终一致性是弱一致性的特定模式。
强一致性与弱一致性: 其实只有两类数据一致性，强一致性与弱一致性。强一致性也叫做线性一致性，除此以外，所有其余的一致性都是弱一致性的非凡状况。所谓强一致性，即复制是同步的，弱一致性，即复制是异步的。<br/>
用户更新网站头像，在某个工夫点，用户向主库发送更新申请，不久之后主库就收到了申请。在某个时刻，主库又会将数据变更转发给本人的从库。最初，主库告诉用户更新胜利。<br/>
如果在返回“更新胜利”并使新头像对其余用户可见之前，主库须要期待从库的确认，确保从库曾经收到写入操作，那么复制是同步的，即强一致性。如果主库写入胜利后，不期待从库的响应，间接返回“更新胜利”，则复制是异步的，即弱一致性。<br/>
强一致性能够保障从库有与主库统一的数据。如果主库忽然宕机，咱们仍能够保证数据残缺。但如果从库宕机或网络阻塞，主库就无奈实现写入操作。<br/>
在实践中，咱们通常使一个从库是同步的，而其余的则是异步的。如果这个同步的从库呈现问题，则使另一个异步从库同步。这能够确保永远有两个节点领有残缺数据：主库和同步从库。这种配置称为半同步。
X/Open DTP 模型与 XA 标准
X/Open，即当初的 open group，是一个独立的组织，次要负责制订各种行业技术标准。官网地址：http://www.opengroup.org/。X/Open 组织次要由各大出名公司或者厂商进行反对，这些组织不光遵循 X /Open 组织定义的行业技术标准，也参加到规范的制订。下图展现了 open group 目前次要成员(官网截图)：
DTP 参考模型：Distributed Transaction Processing: Reference Model
DTP XA 标准：Distributed Transaction Processing: The XA Specification
参考文档
维基百科——数据库事务
维基百科——CAP 定理
数据库事务的概念及其实现原理
详解分布式 BASE 定理
面试必问：分布式事务六种解决方案
漫画：什么是分布式事务？
聊聊分布式事务，再说说解决方案
分布式事务？No, 最终一致性
CAP 定理的含意
分布式事务概述
我是御狐神，欢送大家关注我的微信公众号:wzm2zsd
本文最先公布至微信公众号，版权所有，禁止转载！