数据库事务的ACID特性
数据库事务特性包括原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)。以下单为例，在单体的电商系统中，调用下单服务，整个服务操作在同一事务中完成。下单成功以后，扣减库存，生成订单操作会同时生效，数据都会写入库存数据库，订单数据库。流程如下：
在分布式系统中，如果只是将下单服务进行微服务化，即将下单服务拆分为调用订单服务API和商品服务API。微服务拆分后，订单服务API对应独立的订单数据库，商品服务API对应独立的商品数据库。如果，直接按照单体服务中的的流程，只是将原来的本地方法替换微服务API的话，其流程图如下：
在下单服务中，使用RPC或者HTTP请求调用商品服务API和订单服务API，类似client（客户端）调用server（服务器）方式。此时，如果出现如下两个问题：
- 网络异常，client调用server服务调用成功，但是因为网络异常，client显示调用失败。
- 服务器宕机，client调用server服务调用成功，但是server服务器宕机了，client显示调用失败。
流程图如下：
因为，如上两个原因，会造成商品与订单数据的数据状态不一致，情况如下：
- 订单服务因为网络异常或者服务器宕机，订单数据回滚在订单数据库中没有生成数据，而商品服务调用成功，商品数据库中的库存扣减成功。
- 订单服务调用成功，生成的订单数据写入了订单数据库，而商品服务因为网络异常或者服务器宕机而调用失败，商品数据库中的库存没有变化。
CAP理论以及数据库的两阶段提交（2PC）
如何解决直接拆分为微服务后，数据状态不一致的问题呢？这时，就需要引入分布式事务了。首先，会想到通过数据库的两阶段提交（2PC）方式实现分布式事务，这个属于数据库层面的实现方案。根据CAP理论（详细可以参考深入理解CAP理论和适用场景），2PC属于CP模式。
对数据库分布式事务有了解的同学一定知道数据库支持的2PC，又叫做 XA Transactions。其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：
- 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。
- 第二阶段：事务协调器要求每个数据库提交数据。
其中，如果有任何一个数据库否决此次提交，那么所有数据库操作的数据都会回滚。此种方式会有严重的性能影响，并且也有如下几个缺点：
- 同步阻塞问题！执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源也都处于阻塞状态。
- 单点故障！由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。
- 数据不一致！在二阶段提交的过程中，当协调者向参与者发送commit请求之后，发生了网络异常或者服务器宕机，这会导致部分数据提交成功，部分提交失败，造成数据不一致。
BASE理论
在分布式系统中，一般更加重视系统的可用性，分布式事务解决方案都基于BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：
- Basically Available（基本可用）
- Soft state（软状态）
- Eventually consistent（最终一致性）
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
