分布式事务学习笔记

前言
现在在做的线下收银系统经常出现负库存异常单，经常有店员反映不知道如何处理，导致不能日结。而导致问题的原因是收银系统、订单系统成单后调用库存系统扣库存的时候发现库存不足，导致扣减库存失败。正好在公司wiki的时候偶然看到基于Saga补偿模式的分布式事务设计文档，故而去学习了解了下分布式事务的解决方案。在此对分布式事务解决方案做一些学习整理。

基本概念

事务

事务是指应用程序执行一系列的操作，并且要求这些操作要么全部成功，要么一个也不执行。事务具有四个基本要素ACID。
原子性(Atomicity)：一个事务里面的所有操作要么全部成功，要么失败全部回归，不能只执行一部分；
一致性(Correspondence)：事务开始之前和事务结束以后，数据库的完整性约束没有被破坏；
隔离性（isolation）：多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离；
持久性（Durability）：持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

CAP定理

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

一致性：在分布式环境下，指的是多个数据副本之间能否保持数据一致的特性。将一个数据副本分布在不同的节点上，如果对第一个数据节点进行了更新操作，却没有对第二个节点进行更新操作，在读取第二个节点的数据时读到的是旧的数据，这就是典型的分布式数据不一致的情况。如果对一个数据节点进行更新操作后，所有的用户都能读到最新的数据，那么就任务这个系统具备系统强一致性（严格的一致性）；

可用性：指系统提供的服务必须一致处于可用状态，对于用户的每一个操作总是在有限的时间内返回结果。
有限的时间内：对于用户的一个操作请求，系统必须在指定的时间范围内返回，如果超过这个时间范围，那么系统被任务不可用
返回结果：返回结果是可用性的另外一个指标，它要求系统在完成对用户请求的处理后，能返回一个正常的响应结果。正常的响应结果通常能够反映出对请求处理的结果，即成功还是失败，而不是一个让用户困惑的返回结果

分区容错性：分布式系统在任何分区网络故障的时候，依然需要能够保证对外提供满足一致性、可用性的服务，除非整个网络环境都发生了故障。

BASE理论

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
Basically Available（基本可用）
Soft state（软状态）
Eventually consistent（最终一致性）

2PC（两阶段提交）

2PC是指在各个参与者（业务系统）过程中引入一个协调者，同时将业务系统的执行过程分为准备阶段和提交阶段，协调者根据准备阶段的结果去告知各个系统是做提交本地事务还是回归本地事务。
两个阶段分别是：准备阶段、提交阶段

其中1、2、3属于提交阶段，4、5属于提交阶段
1、协调者向各个系统发送预处理的请求，并且等待处理结果；
2、各系统接收到请求后执行各自的本地事务，但是不会马上提交事务；
3、告知协调者本地事务是否执行成功；
4、协调者根据收到的反馈，判断是要提交事务还是回滚事务，如果所有的参与系统反馈的都是成功则可以提交事务，只要有一个参与者失败则回滚事务；
5、所有的参与者根据协调者的指令提交或回滚事务。

缺点

1、在整个过程中协调者和参与者的资源都会被锁定，只有当所有的参与者都准备完毕之后，协调者才会发起全局提交的指令，各个参与系统才会提交或回滚事务释放资源，对性能有一定的影响；
2、在提交阶段只有协调者或者参与者任何一个节点出现问题，都会导致整个流程阻塞，各个系统的事务无法提交或回滚，资源无法释放；
3、无法100%保证数据的一致性，在提交阶段某个子系统可能出现提交异常或者系统宕机，这个时候数据就会出现不一致的情况。

3PC

3PC是2PC的升级版，它主要引进了超时机制，同时添加多了一个阶段。一旦事务参与者迟迟没有收到协调者的Commit请求，就会自动进行本地commit，这样相对有效地解决了协调者单点故障的问题。

1、2、3为第一阶段：
协调者向各个系统询问是否可以完成事务提交，各个系统检测自身的状态，如果可以调节返回“是”，否则返回“否”；
4、5、6为第二阶段：
在阶段一中，如果所有的参与者都返回Yes的话，那么各系统就进行事务预提交，并将Undo和Redo信息记录到事务日志中（此时属于未提交事务的状态）。然后向协调者反馈“Ack”，并等待协调者的下一步指令。
如果任何一个参与者节点返回的结果是No响应，或者协调者在等待参与者节点反馈的过程中超时。整个分布式事务就会中断，协调者就会向所有的参与者发送终止事务请求。
7、8、9为第三阶段：如果上一阶段所有的参加者都预处理成功，则协调者向所有系统发送提交指令，否则发送终止事务的指令，各系统根据指令进行执行事务

TCC（Try-Confirm-Cancel）补偿事务

补充事务的核心思想是每一个服务都有确认和取消操作。
T（Try）：完成所有业务检查（一致性），预留业务资源(准隔离性)
C（Confirm）：确定执行业务操作，只会占用Try时预留的资源
C（Cancel）：取消Try时预留的业务资源

Try：收银系统预处理自己的业务逻辑，同时调用订单和库存系统的Try接口
Confirm：如果三个系统都Try成功，收银系统执行自己的确认操作，同时调用订单库存系统的确认接口
Cancel：如果有任意一个Try失败，收银系统执行自己的取消操作，同时调用订单库存系统的取消接口

Saga补偿模式分布式事务

Saga由一系列sub-transaction Ti 组成，每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果。和TCC相比Saga没有“预留”动作，它的Ti就是直接提交到库。
Saga是这样跨多个微服务的维持数据一致性的：使用消息或事件将一个个子事务串起一个个本地交易。Saga会依次以向前顺序执行各个事务步骤。如果其中一个步骤失败了，那么Saga就执行补偿事务以相反的顺序来实现回滚。
收银订单库存系统通过消息事件顺序执行，如果某个系统执行失败时，相反的顺序来实现回滚。

作者：张伟峰