分布式事务

1、事务

严格意义上的事务实现应该是具备原子性、一致性、隔离性和持久性，简称 ACID。

• 原子性（Atomicity）：可以理解为一个事务内的所有操作要么都执行，要么都不执行；
• 一致性（Consistency）：可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是300，不会存在我账上钱加了，你账上钱没扣的中间状态；
• 隔离性（Isolation）：指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。
• 持久性（Durability）：指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。

2、CAP理论

• 一致性(Consistency) ：客户端知道一系列的操作都会同时发生(生效)；
• 可用性(Availability) ：每个操作都必须以可预期的响应结束；
• 分区容错性(Partition tolerance) ：即使出现单个组件无法可用，操作依然可以完成。
  

2.1、一致性

数据一致性指（all nodes see the same data at the same time），即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，不能存在中间状态。分布式环境中，一致性是指多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处理一致的状态。

• 强一致性：如果的确能像上面描述的那样时刻保证客户端看到的数据都是一致的，那么称之为强一致性。
• 最终一致性：如果允许存在中间状态，只要求经过一段时间后，数据最终是一致的，则称之为最终一致性。
• 弱一致性：此外，如果允许存在部分数据不一致，那么就称之为弱一致性。

2.2、可用性

系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

• 有限时间内：对于用户的一个操作请求，系统必须能够在指定的时间（响应时间）内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。即这个响应时间必须在一个合理的值内，不让用户感到失望。试想，如果一个下单操作，为了保证分布式事务的一致性，需要10分钟才能处理完，那么用户显然是无法忍受的。
• 返回正常结果：要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

2.3、分区容错性

即分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

3、CAP的权衡

对于分布式系统来说，P是不能放弃的，因此架构师通常是在可用性和一致性之间权衡。

• 放弃P：放弃分区容错性的话，则放弃了分布式，放弃了系统的可扩展性；
• 放弃A：放弃可用性的话，则在遇到网络分区或其他故障时，受影响的服务需要等待一定的时间，再此期间无法对外提供政策的服务，即不可用；
• 放弃C：放弃一致性的话（这里指强一致），则系统无法保证数据保持实时的一致性，在数据达到最终一致性时，有个时间窗口，在时间窗口内，数据是不一致的。

3.1、为什么无法保证一致性和可用性

首先一个前提，对于分布式系统而言，分区容错性是一个最基本的要求，因此基本上我们在设计分布式系统的时候只能从一致性（C）和可用性（A）之间进行取舍。

• 如果保证了一致性（C）：对于节点N1和N2，当往N1里写数据时，N2上的操作必须被暂停，只有当N1同步数据到N2时才能对N2进行读写请求，在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然，这与可用性是相悖的。
• 如果保证了可用性（A）：那就不能暂停N2的读写操作，但同时N1在写数据的话，这就违背了一致性的要求。

3.2、如何选择CAP

• 选择AP的场景：对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 N 个 9，即保证 P 和 A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。
• 选择CA的场景：对于涉及到钱财这样不能有一丝让步的场景，C 必须保证。网络发生故障宁可停止服务，这是保证 CA，舍弃 P。貌似这几年国内银行业发生了不下 10 起事故，但影响面不大，报道也不多，广大群众知道的少。还有一种是保证 CP，舍弃 A。例如网络故障是只读不写。

4、Base理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE基于CAP定理演化而来，核心思想是即时无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

• Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。
  • 响应时间上的损失：当出现故障时，响应时间增加
  • 功能上的损失：当流量高峰期时，屏蔽一些功能的使用以保证系统稳定性（服务降级）
• Soft state（软状态）：与硬状态相对，即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
  • 因果一致性（Causal consistency）:即进程A在更新完数据后通知进程B，那么之后进程B对该项数据的范围都是进程A更新后的最新值；
  • 读己之所写（Read your writes）:进程A更新一项数据后，它自己总是能访问到自己更新过的最新值；
  • 会话一致性（Session consistency）:将数据一致性框定在会话当中，在一个会话当中实现读己之所写的一致性。即执行更新后，客户端在同一个会话中始终能读到该项数据的最新值；
  • 单调读一致性（Monotonic read consistency）:如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值；
  • 单调写一致性（Monotoic write consistency）：一个系统需要保证来自同一个进程的写操作被顺序执行。

5、Base理论的特点

• BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的。
• 它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。
• 在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。

6、Base理论和CAP的关系

BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

7、ACID 和 BASE 的区别与联系

• ACID 是传统数据库常用的设计理念，追求强一致性模型。BASE 支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性；
• ACID 和 BASE 代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此 ACID 和 BASE 又会结合使用。

8、什么是分布式事务

分布式事务顾名思义就是要在分布式系统中实现事务，它其实是由多个本地事务组合而成。
图（https://www.cnblogs.com/crazymakercircle/p/13917517.html#autoid-h2-4-0-0）

9、分布式事物的分类

分布式事务实现方案从类型上去分刚性事务、柔型事务：

• 刚性事务满足CAP的CP理论(XA 协议（2PC、JTA、JTS）、3PC，但由于同步阻塞，处理效率低，不适合大型网站分布式场景);
• 柔性事务满足BASE理论（基本可用，最终一致，其中包括TCC/FMT、Saga（状态机模式、Aop模式）、本地事务消息、消息事务（半消息））。
  • 补偿型；
  • 异步确保型；
  • 最大努力通知型。

10、刚性事务- XA模型

X/Open DTP(Distributed Transaction Process) 是一个分布式事务模型。这个模型主要使用了两段提交(2PC - Two-Phase-Commit)来保证分布式事务的完整性。 在X/Open DTP(Distributed Transaction Process)`模型里面，有三个角色：

• ​AP:Application，应用程序。也就是业务层。哪些操作属于一个事务，就是AP定义的；
• TM:Transaction Manager，事务管理器。接收AP的事务请求，对全局事务进行管理，管理事务分支状态，协调RM的处理，通知RM哪些操作属于哪些全局事务以及事务分支等等。这个也是整个事务调度模型的核心部分；
• RM：Resource Manager，资源管理器。一般是数据库，也可以是其他的资源管理器，如消息队列(如JMS数据源)，文件系统等。

10.1.1、什么XA规范

10.2、XA协议的主要限制

• 必须要拿到所有数据源，而且数据源还要支持XA协议。目前MySQL中只有InnoDB存储引擎支持XA协议；
• 性能比较差，要把所有涉及到的数据都要锁定，是强一致性的，会产生长事务。

10.3、Seata AT 模式

Seata AT 模式是增强型2pc模式。AT 模式： 两阶段提交协议的演变，没有一直锁表

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源；
• 二阶段：提交异步化，非常快速地完成。或回滚通过一阶段的回滚日志进行反向补偿。