分布式事务

分布式事务

分布式事务就是在分布式环境下，出现的事务问题

事务特性：

原子性：事务中的所有操作，要么全部成功，要么全部失败。影响事务的操作，一般指的是增删改，也就是一个事务中，有多个增删改的SQL

一致性：事务开始前到事务结束后，数据状态需要一致。就像是发布文章，自媒体端是文章待审核，App端就不能出现这篇文章，要保持一致

隔离性：多个事物之间的操作相互隔离，互不影响。比如我这边转账不影响你那边支付支付，这就是事务隔离性

因为是隔离性，所以有隔离级别问题

隔离级别

    读未提交：会产生脏读、幻读、不可重复读的问题 （脏读)

    读已提交：会产生幻读、不可重复读的问题（oracle默认）（解决脏读问题）

    可重复读：会产生幻读的问题（mysql默认）（解决不可重复读的问题）

    串行化：没有任何问题，但是相当于锁表，效率极低。所以这种方案不用

不同的隔离级别会产生不同的问题

    脏读：一个事务读到了另一个事务没有提交的数据

    不可重复读：同一个事务中，连续读取两次，得到结果不一样

    幻读：事务操作看到前和看到后的结果不一致，就像出现了幻觉一样

1、在A事务中执行查询，看到两条数据

2、在B事务中执行增加操作，成功插入一条数据

3、在A事务中执行修改操作，发现修改影响行数为3行

可以用isolation配置事务隔离级别

传统事务控制由Connection控制 Mybatis ：SqlSession Spring：基于运行时异常的声明式事务

跨服务 多服务多数据库、多服务单数据库。总体来说，就是出现了多个数据库连接

分布式理论

CAP定理：分布式架构下必定要遵循的定理

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。

Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。

Partition tolerance （分区容错性）：

    Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

    Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务。容忍出现分区的问题

在分布式下面，这三个指标只能满足两个，且P是一定要保证的，因为网络是不可靠的。客户因素，没办法避免

CP：在一定时间内，等待集群节点进行数据同步后，对外提供访问。就是在数据同步的这个时间片内，系统对外不提供服务。数据同步完 了再提供服务 AP：在任何时间内，都对外访问，但是得到的数据可能不一样

CA：反证法，不能同时出现 多个节点要想数据一致，需要时间同步。那么在这个时间内，一定不能对外访问，所以A不成立。如果可以对外访问，那么数据就不一致，所以C就不成立了 如果一定要满足CA，那就没有P，也就不是分布式环境了，是单节点

BASE理论：

    对CAP的一种补充，它放弃强一致性，追求最终一致性 三个思想

    Basically Available（基本可用） 分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。 譬如电商大促，为了应对大流量，暂时停止注册服务，这时注册服务就不可用，但是整个系统是可用的，所以叫基本可用

    Soft State（软状态） 在一定时间内，允许出现中间状态，比如临时的不一致状态。 比如订单状态：待付款、已付款待发货、已发货、已签收、已结束

    Eventually Consistent（最终一致性）： 虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

分布式事务的解决思路

    AP模式：最终一致性 各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。 譬如：增加了一条数据，后面有操作失败了，那么，补偿措施只需要把增加的那条数据删除即可 因为子事务提交了，那么提交后的状态是一个中间状态，也就是软状态

    CP模式：强一致性 各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。 事务执行过程中，会锁定操作的资源，那么这个资源暂时是不可用的。所以整个系统是基本可用 子事务：分支事务 全局事务：事务协调者，用来监控和通知各个分支事务

对比传统事务

Seata

阿里巴巴开源的解决分布式事务的一个方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。

Seata提供了AT、TCC、SAGA和XA事务模式，打造了一站式的分布式解决方案。

Seata 架构 ：

    TC (Transaction Coordinator) 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。 监控和通知各个事务，包括分支事务和全局事务

    TM (Transaction Manager) 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。 执行事务

    RM (Resource Manager) 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

XA模式
工作流程
首先事务管理器告诉事务协调器我要开启全局事务，事务协调器就会记录事务开启的时机，记录成功后，事务管理器会告诉你要调用哪一个分支去执行业务，微服务也就是资源管理器需要向事务协调器注册分支事务，分支事务去执行业务，执行的结果报告给事务协调器，报告事务状态，TC记录分支事务执行的状态，所有的分支执行完毕后，事务管理器告诉事务协调器需要提交或者回滚全局事务了，TC收到消息后检查每个分支事务的状态，如果每个分支事务都是成功的状态，就会向每个分支发送提交命令，但是如果有一个分支事务失败了，就会每个分支发送回滚命令
缺点：
    因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
    依赖关系型数据库实现事务
优点
    事务的强一致性，满足ACID原则。
    常用数据库都支持，实现简单，并且没有代码侵入

AT模式：AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
    seata的AT模式 
        
        阶段一RM的工作（XA不同,执行业务sql直接提交，记录快照）
            - 注册分支事务
            - 记录undo-log（数据快照）
            - 执行业务sql并提交
            - 报告事务状态
        阶段二RM的工作（XA不同，TC收到消息后检查每个分支事务的状态之后,删除undo-log即可）
            一阶段都成功，则提交，删除undo-log
            一阶段有失败，则回滚，恢复undo-log日志，删除undo-log
        优点
            不会死锁
            最终一致性