分布式事务

---

1.CAP定理

1.1.Consistency

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

1.2.Availability

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

1.3.Partition tolerance

Partition（分区）：因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去链接，形成独立分区
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

分布式系统节点通过网络链接，一定会出现分区问题（P）
当分区出现时，系统的一致性（C）和可用性（A）无法同时满足需要做出取舍只能满足CP或AP

2.BASE理论

BASE理论是对CAP的一种解决思路

2.1.Basically Available

Basically Available（基本可用）：分布式系统再出现故障时，允许损失部分可用性，保证核心可用

2.2.Soft state

Soft state（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态

2.3.Eventually Consistency

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

AP模式：各个子事务分别执行和提交，允许出现的结果不一致，然后采用弥补措施恢复数据即可，实现最终一致
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中处于弱可用状态

3.Seata

3.1.XA模式

实现强一致性，依赖数据库机制实现回滚
yml

seata:
  data-source-proxy-mode: XA

给全局事务入口方法添加@GlobalTransactional

3.2.AT模式

实现最终一致性，依赖数据快照实现数据回滚，可能出现脏数据
yml

seata:
  data-source-proxy-mode: AT

3.3.TCC模式

实现最终一致性，不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

Try：资源检查和预留
Confirm：业务执行和提交
Cancel：预留资源的释放

声明TCC接口

@LocalTCC
public interface AccountServiceTCC {
    /**
     * name方法对应Try
     * commitMethod方法对应Confirm默认为conmmit
     * rollbackMethod方法对应Cancel默认为rollback
     * 所有@BusinessActionContextParameter声明的参数都会放在BusinessActionContext上下文当中
     */
    @TwoPhaseBusinessAction(name = "debit", commitMethod = "commitDebit", rollbackMethod = "cancelDebit")
    void debit(
            @BusinessActionContextParameter(paramName = "userId") String userId,
            @BusinessActionContextParameter(paramName = "money") int money);

    /**
     * 二阶段confirm确认方法、可以另命名，但要保证与commitMethod一致
     *
     * @param context 上下文,可以传递try方法的参数
     * @return boolean
     */
    boolean commitDebit(BusinessActionContext context);

    /**
     * 二阶段回滚方法，要保证与rollbackMethod一致
     * 要注意空回滚的判断和幂等性的判断
     * @param context 上下文
     * @return boolean
     */
    boolean cancelDebit(BusinessActionContext context);
}

3.4.Saga模式

没有事务隔离，会有脏写

3.5.四种模式对比

	XA	AT	TCC	SAGA
一致性	强一致性	弱一致	弱一致	最终一致性
隔离性	完全隔离	基于全局锁隔离	基于预留资源隔离	无隔离
代码入侵	无	无	有，编写三个接口	有，编写状态机和补偿业务
性能	差	好	非常好	非常好
场景	对一致性、隔离性有高要求的业务	基于关系型数据库的大多数分布式业务场景都可以	对性能要求较高的事务，有非关系型数据库要参与的事务	业务流程长、业务流程多，参与者包含其他公司或遗留系统服务，无法提供TCC模式要求的三个接口