微服务-10 分布式事务CAP定理&原理+2PC+3PC+TCC介绍
分布式事务CAP定理&原理+2PC+3PC+TCC+Seata应用案例
事务想必大家都不陌生，只要是在编写程序的同时 都会用到事务，分布式架构当中同样也不能少的了事务，
CAP定理 简单概括：无论是 CP还是AP 在同步数据的时候使用的算法都是HASH算法，同步的数据相同，初始的节点Hash相同，要保证CP就要确保一个集群当中只有一个主节点，要保证AP 则 平级节点没限制
回顾一下事务的基础 四大特性：
原子性：操作这些指令时，要么全部成功，要么全部不执行，只要其中一个指令失败，则所有指令全部失败，数据进行回滚，回到执行指令前的数据状态
一致性：事务从一个状态 变换到另一个状态 整体都必须处于一致性状态
隔离性：一个事务与另一个事务需要隔离，数据库也提供了多种方案
持久性：数据一旦存储 就是拥有性存储，即使数据库发生故障也不会丢失数据
回顾一下数据库提供的事务隔离级别：
脏读：指当一个事务正在访问数据，并且对数据进行了修改，而这种数据还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据还没有提交那么另外一个事务读取到的这个数据我们称之为脏数据。依据脏数据所做的操作肯能是不正确的。
不可重复读：指在一个事务内，多次读同一数据。在这个事务还没有执行结束，另外一个事务也访问该同一数据，那么在第一个事务中的两次读取数据之间，由于第二个事务的修改第一个事务两次读到的数据可能是不一样的，这样就发生了在一个事物内两次连续读到的数据是不一样的，这种情况被称为是不可重复读。
幻象读：一个事务先后读取一个范围的记录，但两次读取的纪录数不同，我们称之为幻象读（两次执行同一条 select 语句会出现不同的结果，第二次读会增加一数据行，并没有说这两次执行是在同一个事务中）
|
Isolation
|
脏读
|
幻读
|
不可重复读
|
谁在用?
|
|
读未提交
|
存在
|
存在 |
存在
|
|
|
读已提交
|
不存在
|
存在
|
存在
|
Oracle
|
|
可重复读
|
不存在
|
不存在
|
存在
|
MySql
|
|
串行化
|
不存在
|
不存在
|
不存在
|
|
CAP定理：
cap原则，指在同一个系统中，Consistency一致性 Availability 可用性 Partition tolerance 分区容错性 三者不可兼得。
一致性（C） 在分布式系统中的所有数据备份，在同一时刻是否同样的值，等同于所有节点访问同一份最新的数据副本，
可用性（A）保证每个请求不管成功或者失败都有响应
分区容错性（P） 系统中任意信息的丢失或者失败不会影响系统的继续操作，
CAP描述解析：
假设有节点data1和节点data2，一开始有个数据number=1。之后向data1提交更新，将数据number设置为2。接着data1就需要将更新推送给data2，让data2也更新number数据。
接下来我们分3个场景分析：
1. 在保证C和P的情况下
为了保证数据一致性，data1需要将数据复制给data2，即data1和data2需要进行通信。但是由于网络是不可靠的，我们系统有保证了分区容忍性，也就是说这个系统是可以容忍网络的不可靠的。这时候data2就不一定能及时的收到data1的数据复制消息，当有请求向data2访问number数据时，为了保证数据的一致性，data2只能阻塞等待数据真正同步完成后再返回，这时候就没办法保证高可用性了。
所以，在保证C和P的情况下，是无法同时保证A的。
2. 在保证A和P的情况下
为了保证高可用性，data1和data2都有在有限时间内返回。同样由于网络的不可靠，在有限时间内，data2有可能还没收到data1发来的数据更新消息，这时候返回给客户端的可能是旧的数据，和访问data1的数据是不一致的，也就是违法了C。
也就是说，在保证A和P的情况下，是无法同时保证C的。
3. 在保证A和C的情况下
如果要保证高可用和一致性，只有在网络情况良好且可靠的情况下才能实现。这样data1才能立即将更新消息发送给data2。但是我们都知道网络是不可靠的，是会存在丢包的情况的。所以要满足即时可靠更新，只有将data1和data2放到一个区内才可以，也就丧失了P这个保证。其实这时候整个系统也不能算是一个分布式系统了。
理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质
备注：一致性又分为强一致性（复制同步） 和弱一致性（复制异步，有可能数据丢失） 最终一致性（具有一定的时间差）
阶段性提交：
在分布式系统中，每个节点都知道自己操作的成功与失败，却无法感知其他节点的操作成功或者失败，当一个事务跨多个节点时，为了保持事务的原子性与一致性，而引入一个协调者来统一掌握所有参与者的结果，要么全部成功，要么全部失败
一、两阶段提交（2PC）（XA 协调者 参与者）
两阶段提交又称2PC,2PC是一个非常经典的强一致、中心化的原子提交协议。
这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。
两个阶段：第一阶段：投票阶段 和第二阶段：提交/执行阶段。
举例 订单服务A，需要调用 支付服务B 去支付，支付成功则处理购物订单为待发货状态，否则就需要将购物订单处理为失败状态。
那么看2PC阶段是如何处理的
1、第一阶段：投票阶段
第一阶段主要分为3步
1）事务询问
协调者 向所有的 参与者 发送事务预处理请求，称之为Prepare，并开始等待各 参与者 的响应。
2）执行本地事务
各个 参与者 节点执行本地事务操作,但在执行完成后并不会真正提交数据库本地事务，而是先向 协调者 报告说：“我这边可以处理了/我这边不能处理”。.
3）各参与者向协调者反馈事务询问的响应
如果 参与者 成功执行了事务操作,那么就反馈给协调者 Yes 响应,表示事务可以执行,如果没有 参与者 成功执行事务,那么就反馈给协调者 No 响应,表示事务不可以执行。
第一阶段执行完后，会有两种可能。1、所有都返回Yes. 2、有一个或者多个返回No。
2、第二阶段：提交/执行阶段（成功流程）
成功条件：所有参与者都返回Yes。
第二阶段主要分为两步
1)所有的参与者反馈给协调者的信息都是Yes,那么就会执行事务提交
协调者 向 所有参与者 节点发出Commit请求.
2)事务提交
参与者 收到Commit请求之后,就会正式执行本地事务Commit操作,并在完成提交之后释放整个事务执行期间占用的事务资源。
3、第二阶段：提交/执行阶段（异常流程）
异常条件：任何一个 参与者 向 协调者 反馈了 No 响应,或者等待超时之后,协调者尚未收到所有参与者的反馈响应。
异常流程第二阶段也分为两步
1)发送回滚请求
协调者 向所有参与者节点发出 RoollBack 请求.
2)事务回滚
参与者 接收到RoollBack请求后,会回滚本地事务。
4、2PC缺点
通过上面的演示，很容易想到2pc所带来的缺陷
1）性能问题
无论是在第一阶段的过程中,还是在第二阶段,所有的参与者资源和协调者资源都是被锁住的,只有当所有节点准备完毕，事务 协调者 才会通知进行全局提交，
参与者 进行本地事务提交后才会释放资源。这样的过程会比较漫长，对性能影响比较大。
2）单节点故障
由于协调者的重要性，一旦 协调者 发生故障。参与者 会一直阻塞下去。尤其在第二阶段，协调者 发生故障，那么所有的 参与者 还都处于
锁定事务资源的状态中，而无法继续完成事务操作。（虽然协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
2PC出现单点问题的三种情况
(1)协调者正常,参与者宕机
由于 协调者 无法收集到所有 参与者 的反馈，会陷入阻塞情况。
解决方案:引入超时机制,如果协调者在超过指定的时间还没有收到参与者的反馈,事务就失败,向所有节点发送终止事务请求。
(2)协调者宕机,参与者正常
无论处于哪个阶段，由于协调者宕机，无法发送提交请求，所有处于执行了操作但是未提交状态的参与者都会陷入阻塞情况.
解决方案:引入协调者备份,同时协调者需记录操作日志.当检测到协调者宕机一段时间后，协调者备份取代协调者，并读取操作日志，向所有参与者询问状态。
(3)协调者和参与者都宕机
-
发生在第一阶段： 因为第一阶段，所有参与者都没有真正执行commit，所以只需重新在剩余的参与者中重新选出一个协调者，新的协调者在重新执行第一阶段和第二阶段就可以了。
2)发生在第二阶段 并且 挂了的参与者在挂掉之前没有收到协调者的指令。也就是上面的第4步挂了，这是可能协调者还没有发送第4步就挂了。这种情形下，新的协调者重新执行第一阶段和第二阶段操作。
3)发生在第二阶段 并且 有部分参与者已经执行完commit操作。就好比这里订单服务A和支付服务B都收到协调者 发送的commit信息，开始真正执行本地事务commit,但突发情况，Acommit成功，B确挂了。这个时候目前来讲数据是不一致的。虽然这个时候可以再通过手段让他和协调者通信，再想办法把数据搞成一致的，但是，这段时间内他的数据状态已经是不一致的了！ 2PC 无法解决这个问题。
二、三阶段提交(3PC)
三阶段提交协议（3PC）主要是为了解决两阶段提交协议的阻塞问题，2pc存在的问题是当协作者崩溃时，参与者不能做出最后的选择。因此参与者可能在协作者恢复之前保持阻塞。三阶段提交（Three-phase commit），是二阶段提交（2PC）的改进版本。
与两阶段提交不同的是，三阶段提交有两个改动点。
1、 引入超时机制。同时在协调者和参与者中都引入超时机制。
2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
1、CanCommit阶段
之前2PC的一阶段是本地事务执行结束后，最后不Commit,等其它服务都执行结束并返回Yes，由协调者发生commit才真正执行commit。而这里的CanCommit指的是 尝试获取数据库锁 如果可以，就返回Yes。
这阶段主要分为2步
事务询问 协调者 向 参与者 发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待 参与者 的响应。
响应反馈 参与者 接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No
2、PreCommit阶段
在阶段一中，如果所有的参与者都返回Yes的话，那么就会进入PreCommit阶段进行事务预提交。这里的PreCommit阶段 跟上面的第一阶段是差不多的，只不过这里 协调者和参与者都引入了超时机制 （2PC中只有协调者可以超时，参与者没有超时机制）。
3、DoCommit阶段
这里跟2pc的阶段二是差不多的。
总结
相比较2PC而言，3PC对于协调者（Coordinator）和参与者（Partcipant）都设置了超时时间，而2PC只有协调者才拥有超时机制。这解决了一个什么问题呢？
这个优化点，主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，
自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。
另外，通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。
以上就是3PC相对于2PC的一个提高（相对缓解了2PC中的前两个问题），但是3PC依然没有完全解决数据不一致的问题。
三、TCC （事务补偿机制）
TCC的全称是（Try-Confirm-Cancel）。如下图所示
TCC又可以被称为两阶段补偿事务，第一阶段try只是预留资源，第二阶段要明确的告诉服务提供者，这个资源你到底要不要，对应第二阶段的confirm/cancel，用来清除第一阶段的影响，所以叫补偿型事务。站在开发者层面是能感知到的，这三个方法的业务逻辑，即对资源的操作，开发者是要自己去实现的！ 我们做个案例： 比如，你的订单服务中本来只有一个接口
//修改代码状态
orderClient.updateStatus()；
都要拆为三个接口，即
orderClient.tryUpateStatus()；
orderClient.confirmUpateStatus()；
orderClient.cancelUpateStatus()；
注意了：
面试官如果问你，TCC有什么缺点？这就是很严重的缺点，对代码入侵性大！每套业务逻辑、都要按try(请求资源)、confirm(操作资源)、cancel(取消资源)，拆分为三个接口！
具体每个阶段，每个服务业务逻辑是什么样的呢?
假设，库存数量本来是50，那么可销售库存也是50。账户余额为50,可用余额也为50。用户下单，买了1个单价为1元的商品。流程如下:
Try阶段
订单服务:修改订单的状态为支付中
账户服务:账户余额不变，可用余额减1，然后将1这个数字冻结在一个单独的字段里
库存服务:库存数量不变，可销售库存减1，然后将1这个数字冻结在一个单独的字段里
confirm阶段
订单服务:修改订单的状态为支付完成
账户服务:账户余额变为(当前值减冻结字段的值)，可用余额不变(Try阶段减过了),冻结字段清0。
库存服务:库存变为(当前值减冻结字段的值)，可销售库存不变(Try阶段减过了)，冻结字段清0。
cancel阶段
订单服务:修改订单的状态为未支付
账户服务:账户余额不变，可用余额变为(当前值加冻结字段的值)，冻结字段清0。
库存服务:库存不变，可销售库存变为(当前值加冻结字段的值)，冻结字段清0。
四、Seate （阿里巴巴分布式事务）
去看一下章
浙公网安备 33010602011771号