事务知识理论以及分布式seata事务

事务特性ACID

• A（原子性）：
  答：指事务中所有操作要么全部完成，要么全部失败

• C（一致性）：
  答：指事务执行前后，事务从一个状态到另一个状态都需要保持一致的（A转账给B，A扣了钱，B却没有收到）

• I（隔离性）：
  答：指多个事务在操作同一个数据时，避免事务交叉执行导致数据不一致问题，有效
  防止：脏读、不可重复读、幻读等现象

• D（持久性）：
  答：指事务提交后，将永久保存在数据库，不管期间是否出现宕机，也不会丢失

小知识扩展

• 隔离级别（隔离级别由低到高，mysql数据库默认级别为可重复读）
  

• 事务传播（默认传播机制为propagation_required）
  1、required：如果当前不存在事务，那么就自己新创建一个事务执行，如果存在事务中，那么就加入该事务
  2、required_new：新建新的事务执行，如果当前存在事务中，那就先挂起，等待执行完毕再启动
  3、supports：如果当前存在事务中那就加入该事务，不存在那就以非事务执行
  4、not_supports：以非事务方式执行，如果当前存在事务，那么就先挂起
  5、mandatory：如果当前不存在事务中，那么就抛出异常
  6、never：如果当前存在事务中，那么就抛出异常
  7、nested：如当前存在事务中，那就嵌套在当前事务中执行，如果不存在那就和默认的事务（required）相同效果

分布式事务理论

CAP（帽子理论：分布式系统中一般都满足cp或ca原则，三种同时满足是不可能的，eureka是ap原则和zookeeper是cp原则）

• C（一致性）：
  答：在分布式系统中所有数据备份在某一时刻都是相同的，所有节点在同一时间访问的都是最新的副本

• A（可用性）：
  答：指分布式节点中出现服务崩溃等不可用情况下，也能对访问节点作出快速响应

• P（分区容错性）：
  答：系统中任意数据的丢失或者失败都不会影响系统的正常流程运作

BASE理论（由cap理论演变而成，是一致性和可用性权衡的结果，base理论主要有三个基本概念）

• 基本可用：指的是系统有可能出现故障时，保证请求服务的可用性，能够快速响应符合预期的结果，例如springcloud的hystrix的服务降级

• 软状态：分布式系统不同节点间某个时刻的数据允许存在中间状态，不同节点的数据副本之间进行同步时可能存在时延，如主从同步，；总结：允许短时间内不同步

• 最终一致性：指所有数据副本无论经过任何环境影响以后，最终的数据服务都是一致的

单机事务

答：单机事务使用强一致性（ACID），操作简单有效

分布式事务

答：分布式事务使用弱一致性（BASE），即使无法做到强一致性，但每个业务根据自身的特点采用适当的方式来使系统达到最终一致性

seata实现原理（个人简述）

• 三大角色
  1、TM（发起者/事务管理器）
  2、TC（协调者）
  3、RM（参与者）
• 执行流程
  1、发起者TM向协调者TC申请全局事务id，并保存进本地事务中
  2、发起者TM会拦截并解析参与者RM的业务sql和数据源，并进行代理操作，会把业务sql对应的数据进行操作前后的undo_log记录
  3、发起者TM会根据feign客服端调用接口的时候，把全局事务id放进请求头中，参与者RM在接收到请求是会解析出请求头中的全局事务id，并放入本地事务中，并向seataSerive注册分支
  4、发起者TM把请求接口的结果发送给协调者TC，并由协调者TC去发送相应的请求给各参与者RM进行对应操作（提交或回滚）
  5、如果回滚，那么协调者TC告诉各参与者RM进行分支回滚，各分支会根据全局事务id等信息获取到对应的undo日志记录进行逆向sql生成，进行回滚
  6、最后无论提交或回滚操作都会对undo日记记录进行删除操作

seata分布式事务模式简述

• AT模式（无业务侵入，提交与回滚均交由seata完成，简单接入与操作）
  一阶段：seata会拦截对应的业务sql，进行解析，并对sql所对应的数据进行“before image”备份，备份完毕后进行sql执行，然后再对执行后结果进行“after image”备份，完成后会锁定对应sql记录数据行（行锁）
  二阶段提交：如果在一阶段操作没有任何异常发生，那么就会进行保存的快照信息进行删除并释放锁资源
  二阶段回滚：seata会利用“before image”备份数据进行回滚，但是回滚之前会将对应业务sql的当前数据与“after image”进行对比，如果一致那么就进行数据回滚，如果不一致那就表明数据已被脏写，需要进行人工干预操作

• TCC模式（业务侵入，无AT模式全局锁，性能更优）
  try：调用 Try 接口，尝试执行业务，完成所有业务检查，预留业务资源（预留资源是指对需要操作的数据进行保存起来，方便后续cancel时用到，譬如：用户资产表三个字段（已用、可用、冻结），try阶段需要减扣可用数据，把对应数值存放到冻结字段中）
  confirm：对业务系统做确认提交，确认执行业务操作，不做其他业务检查，只使用 Try 阶段预留的业务资源
  concel：在业务执行错误，需要回滚的状态下执行业务取消，释放预留资源