分布式事务CAP, 2PC, 3PC,

什么是分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点上.通常一个分布式事务中会涉及对多个数据源或业务系统的操作。

我们可以设想一个业最典型的分布式事务场景： 一个跨银行的转账操作涉及调用两个异地的银行服务，其中一个是本地银行提供的取款服务，另外一个则是目标银行提供的存款服务，这两个服务本身是无状态并且是互相独立的，共同构建了一个完整的分布式系统。如果从本地银行取款成功，但是因为某种原因存款服务失败了，那么就必须回滚到取款前的状态，否则用户可能发现自己的钱不翼而飞了。

对于本地事务处理或者集中式的事务处理系统，很显然我们可以采用已经被实践证明很成熟的ACID模型来保证数据的严格一致性。但是随着分布式事务的出现，传统的单机事务模型已无法胜任。
对于一个高访问量、高并发的互联网分布式系统来说，如果我们严格期望实现一套满足ACID特性的分布式事务，很可能出现的情况就是在系统的可用性和严格一致性之间出现冲突，因为当我们要求分布式系统具有严格一致性时，很可能就需要牺牲掉系统的可用性。因此，在可用性和一致性之间永远无法存在一个两全其美的方案，于是如何构建一个兼顾可用性和一致性的分布式系统成为了无数工程师探讨对难题，出现了诸如CAP和BASE这样的分布式系统经典理论。

什么是CAP定理

2000年，CAP理论由加州大学伯克利分校… balabala …

CAP理论告诉我们，一个分布式系统不可能同时满足:一致性(C:Consistency)、可用性(A:Availability)和分区容错性(P: Partition tolerance)这三个基本需求，最多只能满足其中两项。

一致性
在分布式环境中，一致性时指在多个数据副本之间是否能保持一致性的特性。
在一致性的需求下，当一个系统在数据一致的状态下执行更新操作之后，应该保证系统的数据仍然处于一致性的状态。

对应一个将数据副本分布在不同分布式节点的系统来说，如果对第一个节点的数据进行了更新操作成功之后，却没有使得第二个节点商店额数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是老数据(或称为脏数据)，这就是典型的分布式数据不一致情况。
在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功之后，所有的用户都可以读取到其最新的值，那么这样的系统就可以认为具有强一致性。

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

• 有限对时间内是指： 对于用户的一个操作请求，系统必须在指定时间内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为不可用。对于不同类型的业务类型的系统，对于有限的时间期望值有所差异，但必须存在一个合理的时间。
• 返回结果时可用性的一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果能够正确的反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

返回OutOfMemoryEroor或System Has Crashed等提示语，我们认为系统是不可用的。

分区容错性
分区容错性约束来一个分布式系统要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
网络分区是指在分布式系统中，不同的节点分布在不同的自网络(机房或一定网络等)中，由于一些特殊的原因导致这些子网络之间出现网络不连通的状况，但各个自网络的内部网络是正常的，从而导致整个系统的网络环境被切割成若干个孤立的区域。

CAP理论

放弃CAP定力	说明
放弃P	如果希望能够避免分区容错性问题，一种较为简单的做法就是将所有的数据都放在一个分布式节点上。这样的做法虽然无法100%保证系统不会出错，但是只是奥不会碰到由于网络分区带来的负面影响。但放弃P，同事也意味着放弃了系统的可扩展性
放弃A	放弃可用性的做法是指，一旦系统遇到网络分区或其他故障时，那么受到影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供正常的服务，即不可用。
放弃C	这里所说的放弃一致性，并不是完全不需要数据一致性。事实上，放弃一致性是指放弃数据的强一致性,而保留数据的最终一致性。这样的系统无法保证数据保持实时的一致性，但是能够承诺的是，数据最终会达到一致性的状态.这就引入了一个时间窗口的概念，具体多久能够达到数据一致性取决于系统的设计，主要包括数据副本不同节点之间的复制时长决定。

一个分布式系统不可能同时满足CAP三个需求。
另一方面需要明确的是： 对于一个分布式系统而言，分区容错性可以说是一个最基本的要求。因为，既然是一个分布式系统，那么分布式系统的组件必然会部署到不同的节点，否则就无所谓分布式系统了，因此必然会出现子网络，网络问题又是一个必然会出现的异常情况。
因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题，因此系统架构师往往需要把经理花在如何根据业务特点在C和A之间寻求平衡。

BASE理论

BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写，是由eBay的架构师第一次明确提出的。
BASE是对CAP中一致性和可用性权衡的结果，来源于大规模互联网系统分布式实践的总结，其核心思想是无法做到强一致性，但是每个应用都可以根据自身的业务特点，采用适当的方式使系统达到最终一致性。

基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性,但不等价于系统不可用。

• 响应时间上的损失： 通常情况下一个在线搜索引擎要在0.5s内返回用户相应的查询结果，由于故障响应时间增加到1~2s
• 功能上的损失：某些大促购物高峰的时候，由于消费者购物行为激增，为了保证系统的稳定性，部分消费者可能会被引导至一个降级页面。

软状态
和硬状态相比，是允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性， 即允许系统在不同节点的数据进行数据同步的过程存在延迟

最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间之后，最终能到达到一个一致的状态。

一致性协议

2PC 和 3PC
在分布式系统中，每一个机器节点虽然都能够明确的直到自己在进行事务操作中的结果时成功或失败，但却无法直接获取其他分布式节点的操作结果。因此，当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID特性，就需要引入一个称为协调者(Coordinator)的组件来统一调度所有分布式节点的执行逻辑,这些分布式节点则被称为参与者(Participant)

2PC

2PC是Two-Phase commit的缩写,即二阶段提交。
目前，绝大多数关系型数据库都是采用二阶段提交协议来完成分布式事务处理的，利用该协议能够非常方便的完成多有分布式事务参与者的协调，统一决定事务的提交或者回滚。

协议说明
顾名思义，二阶段提交协议是将事务提交过程分为了两个阶段来处理，器质性的流程如下。

阶段一 : 提交事务请求

• 1.事务询问 : 协调者向所有参与者发送事务内容，询问是否可以执行提交操作，并开始等待各参与者的响应。
• 2.执行事务: 各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中
• 3.各参与者向协调者返回事务询问的响应： 如果参与者成功的执行了事务，则反馈给协调者YES响应;否则返回No响应。

由于上述的内容形式上近似是协调者组织各参与者对一次事务操作的投票表态过程，一次二阶段提交的阶段一也称为投票阶段。

阶段二： 执行事务提交
在阶段二中，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况下，有两种情况。

• 执行事务提交： 假设所有参与者反馈都是YES响应，那么就会执行事务提交。

1. 发送提交请求： 协调者向所有参与者发出Commit请求。
2. 事务提交: 参与者接收到commit请求之后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
3. 反馈事务提交结果： 参与者在完成事务提交之后，向协调者发送Ack消息
4. 完成事务：协调者接收到参与者反馈的Ack消息后，完成事务。
   

• 中断事务： 任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

5. 发送回滚请求： 协调者向所有参与者节点发出Rollback请求。
6. 事务回滚： 参与者接收到rollback请求后，会利用其在阶段一种记录的Undo信息来执行事务回滚操作，并在回滚之后释放在整个事务执行期间占用的资源。
7. 返回事务回滚结果
8. 中断事务
   

以上就是二阶段提交过程中，前后两个阶段分别进行的处理逻辑。
简单来讲：二阶段提交将事务处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试、后提交的处理方式,因此也可将二阶段提交看做一个强一致性算法。

优缺点
二阶段提交协议优点：原理简单，实现方便。
缺点是： 同步阻塞，单点问题，脑裂，太过保守。

• 同步阻塞： 在二阶段提交的执行过程，所有参与事务操作的逻辑都处于阻塞状态。也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作。
• 单点问题：一旦协调者出现问题，整个二阶段提交流程将无法运转，更为严重的是，如果协调者在阶段二出现问题的话，那么其他参与者将会一直处于锁定事务资源的状态中，而无法完成事务操作。
• 数据不一致： 在阶段二，当协调者向所有参与者发送Commit请求后，发生了局部网络异常或者协调者尚未发送完commit请求之前自身崩溃了，最终导致只有部分参与者受到了commit请求。这样会使得分布式系统出现数据不一致性现象。

3PC

3PC是Three-Phase commit的缩写，即三阶段提交，是2PC的改进版，将二阶段提交协议的提交事务请求(阶段一)过程一份为二，形成了CanCommit,PreCommit,doCommit三个阶段组成的事务协议。

阶段一： CanCommit
1.事务询问：协调者向所有参与者发哦少年宫一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始登台各参与者响应
2. 各参与者向协调者反馈事务询问的响应：参与者在接收到协调者的canCommit请求之后，正常情况下，如果自身可以顺利执行事务，那么反馈YES响应，否则返回NO响应。

阶段二：PreCommit
在阶段二，协调者根据参与者的反馈情况来决定是否可以进行的事务PreCommit,正常情况下，有两种可能：

执行事务预提交: 所有参与者反馈都是yes响应。
3. 发送预提交请求：协调者向所有参与者发送preCommit请求，并进入Prepare阶段
4. 事务预提交： 参与者收到协调者preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中
5. 各参与者向协调者反馈市事务执行的响应: 如果事务参与者成功执行了事务，那么就会反馈给协调者ACK响应，同时等待最终的指令：提交(commit)或终止(abort)

中断事务： 假设任何一个参与者向协调者反馈了No响应，或在等待超时之后，协调者尚无法受到所有参与者反馈响应，那么就会中断事务。
6. 发送中断请求： 协调者向所有参与者节点发送abort请求
7. 中断事务： 无论是受到协调者abort请求，或者是等待协调者请求过程中出现超时，参与者都会中断事务。

阶段三： doCommit
该阶段进行真正的事务提交，会出现如下两种可能。

执行提交
8. 发送提交请求： 协调者接收到所有参与者的Ack响应，那么它将从预提交状态转换到提交状态，并向所有参与者发送doCommit请求。
9. 事务提交：参与者接收到doCommit请求之后，会正式的执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
10. 返回事务提交结果： 参与者在事务提交之后，向协调者发送Ack消息
11. 完成事务
12.

中断事务：假设任何一个参与者向协调者反馈了No响应，或在等待超时之后，协调者尚无法受到所有参与者反馈响应，那么就会中断事务。

1. 发送中断请求：协调者向所有参与者发送abort请求
2. 事务回滚
3. 反馈事务回滚结果
4. 中断事务

需要注意的是，一旦进入了阶段三，可能会存在如下两种故障
12. 协调者出现问题
13.协调者和参与者之间网络出现故障
无论出现那种情况，最终都会导致参与者无法及时接收到来自协调者的doCommit或者abort请求，针对针对这样的异常情况，参与者都会在等待超时之后，继续进行事务提交。

优缺点