分布式事务的分析与解决方案的总结

什么是事务

事务由单独单元的一个或者多个SQL语句组成，在这个单元中，每个语句相互依赖，而整个单元作为一个不可分割的整体。如果单元中某条SQL语句执行失败或者产生错误，整个单元就会回滚，所有受影响的数据将会返回到事务开始以前的状态。如果单元中所有的SQL都执行成功，则事务被顺利执行。

• 原子性
  一个事务不可再分割，要么都执行，要么都不执行
• 一致性
  一个事务的执行会使数据从一个一致状态切换到另一个一致的状态
• 隔离性
  一个事务的执行不受其他事务的干扰
• 持久性
  一个事务一旦被提交，则会永久改变数据库的数据

什么是分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别处于不同的分布式系统的不同节点上，简单来说，就是一次大的操作由不同的小操作组成，这些小操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要不全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

最终一致性

比如说张三给里斯转账，虽然张三被扣款了，但是李四不会立即收到钱，这时候就出现了不一致性，但是过了一个小时之后最终又收到了，这就满足了最终一致性。

分布式事务详解

• 本地事务
  
• 分布式事务-跨库服务
  
  分布式事务-微服务
  

分布式事务解决方案

• 跨库：两阶段提交协议2PC
  
  若第二阶段失败了，怎么办
  采取多次提交的方式，或者记录日志，进行人工干预
  分布式事务不可能100%解决，只可以尽量提高成功的概率

• 微服务架构下：TCC
  Try Confirm Cancel两阶段补偿方案
  

1. 这种方案需要在库表中多添加一些字段记录来表示冻结资源数量，同时需要多开发一些接口，即try/confirm/cancel三个api

store	frozen
10	1

2. 若第二阶段提交存在网络异常，或者其他原因，则需要多次调用接口，这时候需要保证接口调用的幂等性，即接口无论执行多少次，其结果都是一样的

• 最大努力通知方案
  最简单的一种柔性事务，适用于一些与最终一致性时间敏感度低的业务，且被动方处理结果不影响主动方的处理结果。典型的使用场景：如银行通知，商户通知等。
  
• 可靠消息最终一致性方案
  基于Rocket MQ
  

TCC与XA/JTA对比

• XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会慈幼资源的锁
• TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁

TCC开源框架的实现
Atomikos、tcc-transaction、ByteTcc、支付宝GTS