3. BASE介绍

BASE模型包含个三个元素：

BA：Basically Available，基本可用
系统出现了不可预知的故障，但还是能用，相比较正常的系统而言会有==响应时间==上的损失和功能上的损失。

S：Soft State，==软状态==，状态可以有一段时间不同步
什么是软状态呢？相对于原子性而言，要求多个节点的数据==副本都是一致==的，这是一种“硬状态”。

软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在==数据延时==。

E：Eventually Consistent，==最终一致==，最终数据是一致的就可以了，而不是时时保持强一致。
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

5. 分布式事务两种方案

5.1 XA模式

数据库支持的 2PC【2 phase commit 二阶提交】，又叫做 XA Transactions。

MySQL 从 5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。 其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是 否可以提交。

第二阶段：事务协调器要求每个数据库提交数据。 其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务 中的那部分信息。

==优势==
XA 模式比较简单，而且一旦商业数据库实现了 XA 协议，使用分布式事务的成本也比较低。
==劣势==
XA 性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景。
XA 目前在商业数据库支持的比较理想，在 mysql 数据库中支持的不太理想，mysql 的 XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。
许多 nosql 也没有支持 XA，这让 XA 的应用场景变得非常狭隘。

5.2 柔性事务-TCC 事务补偿型方案

​TCC 的基本概念​

​TCC是Try-Confirm-Cancel 的简称:

​Try阶段：​

​完成所有业务检查（一致性），预留业务资源(准隔离性)​

​Confirm阶段：​

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

​Cancel阶段：​

取消Try阶段预留的业务资源。

5.3 XA和TCC的区别

XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。

XA事务中的两阶段提交内部过程是对开发者屏蔽的，回顾我们之前讲解JTA规范时，通过UserTransaction的commit方法来提交全局事务，这只是一次方法调用，其内部会委派给TransactionManager进行真正的两阶段提交，因此开发者从代码层面是感知不到这个过程的。而事务管理器在两阶段提交过程中，从prepare到commit/rollback过程中，资源实际上一直都是被加锁的。如果有其他人需要更新这两条记录，那么就必须等待锁释放。

TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

​TCC中的两阶段提交并没有对开发者完全屏蔽，也就是说从代码层面，开发者是可以感受到两阶段提交的存在。开发者明显的感知到了两阶段提交过程的存在。try、confirm/cancel在执行过程中，一般都会开启各自的本地事务，来保证方法内部业务逻辑的ACID特性。