微服务之分布式事务 (一)

分布式事务

一、什么是事务：

1.  事务是由数据库中操作的最小单位，是作为单个逻辑单元执行的一系列操作；这些操作一起向系统提交，要么都成功，要么都失败，事务是一组不分割的操作单元。

        事务具备ACID的特性，即原子性、一致性、隔离性和持久性          

              原子性（atomicity）：个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。

              一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态，事务的中间状态不能被观察到的。

               隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。隔离性又分为四个级别：读未提交(read uncommitted)、读已提交(read committed，解决脏读)、可重复读(repeatable read，解决虚读)、串行化(serializable，解决幻读)。

              持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

    任何事务机制在实现时，都应该考虑事务的ACID特性，包括：本地事务、分布式事务，及时不能都很好的满足，也要考虑支持到什么程度。

     2. 本地事务：当事务由本地的资源管理器本地管理的时候，我们称为本地事务，本地事务能够严格的执行ACID的特性，高效，可靠，状态都在本地的资源管理器中维护

      而且应用编程模型简单，但是本地事务不具备的分布式事务的处理的能力，隔离的最小单位也受限于本地资源管理器。常用于传统的单模块项目中使用

     3.全局事务：有全局的事务的管理进行全局的管理，全局的事务管理器负责全局的事务状态和参与的资源，协同资源进行一致性的提交回滚 

  柔性事务中的服务模式：

1. 可查询操作：服务操作具有全局唯一的标识，操作唯一的确定的时间。
2. 幂等操作：重复调用多次产生的业务结果与调用一次产生的结果相同。一是通过业务操作实现幂等性，二是系统缓存所有请求与处理的结果，最后是检测到重复请求之后，自动返回之前的处理结果。
3. TCC操作：Try阶段，尝试执行业务，完成所有业务的检查，实现一致性；预留必须的业务资源，实现准隔离性。Confirm阶段：真正的去执行业务，不做任何检查，仅适用Try阶段预留的业务资源，Confirm操作还要满足幂等性。Cancel阶段：取消执行业务，释放Try阶段预留的业务资源，Cancel操作要满足幂等性。TCC与2PC(两阶段提交)协议的区别：TCC位于业务服务层而不是资源层，TCC没有单独准备阶段，Try操作兼备资源操作与准备的能力，TCC中Try操作可以灵活的选择业务资源，锁定粒度。TCC的开发成本比2PC高。实际上TCC也属于两阶段操作，但是TCC不等同于2PC操作。
4. 可补偿操作：Do阶段：真正的执行业务处理，业务处理结果外部可见。Compensate阶段：抵消或者部分撤销正向业务操作的业务结果，补偿操作满足幂等性。约束：补偿操作在业务上可行，由于业务执行结果未隔离或者补偿不完整带来的风险与成本可控。实际上，TCC的Confirm和Cancel操作可以看做是补偿操作。

常见的柔性分事务实现方式：

（一）、TCC事务补偿型方案

    1. 什么是TCC？

    TCC 分别对应Try、confirm和cancel的三种操作。

           - Try：预留业务资源

           - Confirm：确认执行业务操作

           - Cancel：取消执行业务操作

   2.TCC与事务的关联？

          - Try操作是先把多个对应的业务资源进行预留锁定。为后面业务的处理打下接触，就像表结构操作相关，每次表结构的更新都会锁定数据库对应的表就数据。保持数据库的资源

         - Confirm操作是在Try操作之后执行，使用Try预留的业务资源进行确认，使用预留的业务资源和commit相似

         - Cancel则是当Try操作中涉及的所有应用没有全部成功，需要将已成功的应用进行取消(即Rollback回滚)。其中Confirm和Cancel操作是一对反向业务操作。 

场景举例：

       在我们在使用第三方服务乘坐飞机的购买机票的时候，如果从A地到B地点，但是由于A没有直达到B的的飞机，这个时候，我们的第三方服务就就会给我推荐一个中转线路。从A先到C，然后从C在到B

这个时候，我们会考虑这个线路出发，如下图：

但是这个线路要通过第三方的服务去订购两个航司的机票。如果说有一方航司失败，这次的出行就没有办法去完成，例如，订购了从A到C的中国航空机票，但是因为其他原因没有订到从C到B机票，

又例如订到了C到B的海南航空机票，但是却没有A到C的机票，这个出行都没有办法去完成，而且大家都知道，在预定机票取消的时候，我们会扣除手续费，而这个手续费呢，如果从我们身上出，我们肯定是不会同意，但是如果从第三方

代理商，那么怎么来做，都不会扣钱呢？？？

首先：航空公司为第三方服务商提供了3个接口：机票的预留接口,机票确定接口和取消接口。第三方服务通过两个阶段调用：

阶段一：

第三方服务分别请求两个航司，进行机票的预留，两个航司会返回预留的结果，而航司则要确保预留成功的机票最后都能够购买

阶段二：

 如果两个航空公司都预留成功，则分别向两个公司发送确认购买请求

 如果两个航空公司有任何一个出现预留失败，就取消预留成功的，在这种情况下，即便是失败也不会扣用户的钱，因为至少预留，并没有发生购买

 通过这种方案，我们可以保证在购买机票的时候，能够达到一致性，要么都成功，要么都失败，当然在实际的场景中，肯定比这要复杂的多，不让支付时间的，网络延迟等等问题，但是这个例子，至少简单的描述一下TCC事务

 TCC的每项操作执行动作

        Try操作： 完成所有业务检查（一致性），预留业务资源(准隔离性) ，阶段一中的预留动作

        Confirm操作：确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源。阶段二中的确认动作

        Cancel操作：取消Try阶段预留的业务资源。阶段二中的取消动作