BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果。BASE 理论核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性
BASE 和 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。
2.2基于 XA 协议的两阶段提交X/Open 组织提出了分布式事务的规范——XA 协议，XA 协议包含两部分：事务管理器和本地资源管理器。
其中本地资源管理器往往由数据库实现，目前主流的关系型数据库都实现了 XA 接口， 而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。
XA 的核心，便是全局事务，通过XA 二阶段提交协议，与各分布式数据交互，分准备与提交两个阶段逻辑流程如下图：
在 XA 协议中事务分为两阶段：
事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。
事务协调器要求每个数据库提交数据，或者回滚数据。
优点：
尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于 MySQL 是从 5.5 开始支持。
缺点：
单点问题：事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交 的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。
同步阻塞：在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。
数据不一致：两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能。
比如在第二阶段中，假设协调者发出了事务 Commit 的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了 Commit 操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。 两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。
2.3 3 PC 事务3PC，全称 “three phase commit”，是 2PC 的改进版，其将 2PC 的 “提交事务请求” 过程一分为二。
如下图所示：
1.事务询问：协调者向所有的参与者发送一个包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2.各参与者向协调者反馈事务询问的响应：参与者接收来自协调者的 canCommit 请求，如果参与者认为自己可以顺利执行事务，就返回 Yes，否则反馈 No 响应。这一阶段主要是确定分布式事务的参与者是否具备了完成commit 的条件，并不会执行事务操作。
2.3.2第二阶段：precommit协调者在得到所有参与者的响应之后，会根据结果执行 2 种操作：执行事务预提交，或者中断事务。
1.执行事务预提交分为 3 个步骤：
发送预提交请求：协调者向所有参与者节点发出 preCommit 的请求，并进入 prepared 状态。
事务预提交：参与者受到 preCommit 请求后，会执行事务操作，对应 2PC 中的 “执行事务”，也会 Undo 和 Redo 信息记录到事务日志中。
各参与者向协调者反馈事务执行的结果：如果参与者成功执行了事务，就反馈 Ack 响应，同时等待指令：提交（commit） 或终止（abor）。 2.中断事务也分为 2 个步骤：
发送中断请求：协调者向所有参与者节点发出 abort 请求 。
中断事务：参与者如果收到 abort 请求或者超时了，都会中断事务。
2.3.3第三阶段：docommit1.执行提交
发送提交请求：进入这一阶段，如果协调者正常工作，并且接收到了所有协调者的 Ack 响应，那么协调者将从 “预提交” 状态变为 “提交” 状态，并向所有的参与者发送 doCommit 请求 。
事务提交：参与者收到 doCommit 请求后，会正式执行事务提交操作，并在完成之后释放在整个事务执行期间占用的事务资源。
反馈事务提交结果：参与者完成事务提交后，向协调者发送 Ack 消息。