1.前言
此篇详细讲解了分布式事务相关知识，希望能帮助到你，一起学习加油吧！
2. 分布式事务
2.1. 分布式事务出现场景
在多种业务场景下，单机事务无法满足业务需求，涉及到分布式事务的需求，如以下几种情况：
-
跨库事务：业务逻辑本身操作了多个库。
-
分库分表：分库分表后涉及多库/表数据的读写。
-
微服务架构下服务间请求
2.2. 分布式事务缺陷之 CAP 定理
2.2.1. CAP 概念
对于分布式事务，有以下三个特性：一致性，可用性与分区容错性。
-
一致性 (Consistency)
数据一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，不能存在中间状态。
分布式环境中，一致性是指 多个副本之间能否保持一致的特性 。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处理一致的状态。
数据一致性分为强一致性、弱一致性、最终一致性：
-
如果的确能像上面描述的那样时刻保证客户端看到的数据都是一致的，那么称之为强一致性。
-
如果允许存在中间状态，只要求经过一段时间后，数据最终是一致的，则称之为最终一致性。
-
此外，如果允许存在部分数据不一致，那么就称之为弱一致性。
-
-
可用性 (Availability)
系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在 有限的时间 内返回 正常的结果 。
-
分区容错性 (Partition tolerance)
即分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
2.2.2. 分布式事务的权衡
对于 C、A、P 三个方面，同时满足这是不可能的。2000 年 7 月 Eric Brewer 教授仅仅提出来的是一个猜想，2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP 理论，并且而一个分布式系统最多只能满足 CAP 中的 2 项。之后，CAP 理论正式成为分布式计算领域的公认定理。
可以做一个假设，对于分布式事务，通常分区容错性是需要做到的，如果做不到，那么分布式就没有意义了。在此基础上，对于 AP 两个方面，如果需要满足一致性 (强一致性)，那么意味着任意时刻所有节点数据都应该相同。这就意味着对任一节点数据的读写必须同步到其他节点，其他节点在此期间无法操作该数据，否则就会造成数据不一致。由于这个限制，可用性就无法保证。如果在写入期间数据阻塞时间很长，那么必然会导致可用性的丧失。
-
放弃 P
放弃分区容错性的话，则放弃了分布式，放弃了系统的可扩展性。
-
放弃 A
放弃可用性的话，则在遇到网络分区或其他故障时，受影响的服务需要等待一定的时间，再此期间无法对外提供政策的服务，即不可用。
-
放弃 C
放弃一致性的话 (这里指强一致)，则系统无法保证数据保持实时的一致性，在数据达到最终一致性时，有个时间窗口，在时间窗口内，数据是不一致的。
在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性。但是对于金融业务而言，一致性往往是更重要的。对于金融数据甚至可以牺牲可用性来保证一致性，即使不可用也要保证数据是一致的。
2.2.3. CAP 与 ACID 的区别
-
A 的区别:
ACID 中的 A 指的是原子性 (Atomicity)，是指事务被视为一个不可分割的最小工作单元，事务中的所有操作要么全部提交成功，要么全部失败回滚; CAP 中的 A 指的是可用性 (Availability)，是指集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
-
C 的区别:
ACID 一致性是有关数据库规则，数据库总是 从一个一致性的状态转换到另外一个一致性的状态 。CAP 的一致性是 分布式多服务器之间复制数据令这些服务器拥有同样的数据 ，由于网速限制，这种复制在不同的服务器上所消耗的时间是不固定的，集群通过组织客户端查看不同节点上还未同步的数据维持逻辑视图，这是一种分布式领域的一致性概念。
ACID 里的一致性指的是事务执行前后，数据库完整性，而 CAP 的一致性，指的是分布式节点的数据的一致性。背景不同，无从可比。
2.3. CAP 扩展之 BASE 理论
CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸，对于 C 我们采用的方式和策略就是 保证最终一致性 。
BASE 是 Basically Available (基本可用)、Soft state (软状态) 和 Eventually consistent (最终一致性) 三个短语的缩写。BASE 基于 CAP 定理演化而来，核心思想是即时无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
-
Basically Available (基本可用)
基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用 性，但不等于系统不可用。允许响应时间的损失 (时间变长) 与功能的损失 (服务降级)。
-
Soft state (软状态)
指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
-
Eventually consistent (最终一致性)
强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
Eventually 含义为最终的意思，关于词典的解释为
in the end, especially after a long time or a lot of effort, problems, etc.。即意味着 无论经过多长的时间，耗费多少的努力，都要达到这一目标，数据的最终一致性 。对于最终一致性，又可分为以下几种：
-
因果一致性 (Causal consistency)
即进程 A 在更新完数据后通知进程 B，那么之后进程 B 对该项数据的范围都是进程 A 更新后的最新值。
-
读己之所写 (Read your writes)
进程 A 更新一项数据后，它自己总是能访问到自己更新过的最新值。
-
会话一致性 (Session consistency)
将数据一致性框定在会话当中，在一个会话当中实现读己之所写的一致性。即执行更新后，客户端在同一个会话中始终能读到该项数据的最新值。
-
单调读一致性 (Monotonic read consistency)
如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
-
单调写一致性 (Monotoic write consistency)
一个系统需要保证来自同一个进程的写操作被顺序执行。
-
BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的。BASE 理论的核心思想是: 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性 。
BASE 理论是对 CAP 理论的延伸和补充，主要是对 AP 的补充。牺牲数据的强一致性，来保证数据的可用性，虽然存在中间装填，但数据最终一致。
ACID 是传统数据库常用的设计理念，追求强一致性模型。BASE 支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。ACID 和 BASE 代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此 ACID 和 BASE 又会结合使用。
2.4. 刚性事务
刚性事务指的是分布式事务要像本地式事务⼀样，具备数据强⼀致性。从 CAP 来看就是要达到 CP 状态。
常见的刚性事务方案有：XA 协议（2PC、JTA、JTS）、3PC。由于刚性事务同步阻塞，处理效率低，不适合⼤型⽹站分布式场景。
2.4.1. 刚性事务之 XA 模型
XA 规范是 X/Open 组织定义的分布式事务处理 (DTP，Distributed Transaction Processing) 标准。规范描述了全局的事务管理器与局部的资源管理器之间的接口。
对于 XA 模型，包含三个角色：
-
AP：Applicaiton，应用程序
业务层，哪些操作属于⼀个事务，就是 AP 定义的。
-
TM：Transaction Manager
接收 AP 的事务请求，对全局事务进⾏管理，管理事务分⽀状态，协调 RM 的处理，通知 RM 哪些操作属于哪些全局事务以及事务分⽀等等。这个也是整个事务调度模型的核⼼部分。
-
RM：Resource Manager，资源管理器
⼀般是数据库，也可以是其他的资源管理器，如消息队列 (如 JMS 数据源)，⽂件系统等。
XA 规范的目的是允许多个资源 (如数据库，应用服务器，消息队列等) 在同一事务中访问，这样可以使 ACID 属性跨越应用程序而保持有效。XA 规范使用两阶段提交 (2PC，Two-Phase Commit) 协议来保证所有资源同时提交或回滚任何特定的事务。目前知名的数据库，如 Oracle, DB2, mysql 等，都是实
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
