本分布式事务系列主要讲分布式事务从
理论-> 解决方案 -> 使用框架 -> 实现及原理 -> 案例实战 -> 事务回滚（全局异常统一处理）->分布式事务消息
该篇着重于讲述分布式事务的基础理论。因为它本身就是一个偏理论性的难题。
- 分布式事务产生背景
- ACID酸碱平衡理论
- CAP帽子原理
- 分布式事务案例分析--支付接口
- Base理论
一、分布式事务产生背景
在微服务环境下，因为会根据不同的业务会拆分成不同的服务，比如酒店服务、订单服务、会员服务等，让专业的人做专业的事情，每个服务都有自己独立的数据库，并且是独立运行，互不影响。
服务与服务之间通讯采用RPC远程调用技术，但是每个服务中都有自己独立的数据源，即自己独立的本地事务。两个服务相互通讯的时候，两个本地事务互不影响，从而出现分布式事务，这就是分布式事务产生的原因。
通俗的讲，两个人A与B都提着不同的篮子，里面装着鸡蛋。A装鸡蛋时篮子掉了打碎了鸡蛋，是碎不了B的蛋的...
注意：传统项目大部分情况下，不会产生分布式事务，但是在项目中如果采用多数据源方式。就也会出现该问题。
分布式事务产生背景原理图：
这里是一个很经典的案例(伪代码)，下单扣库存。订单模块增加一条数据，执行成功后调用库存服务，库存扣减方法执行完毕后无错误即进行数据提交，此时库存减少。调用完成后订单模块报错，那么在事务机制下，订单模块操作的数据会被回滚，从而出现了订单回滚，库存扣减现象，这就是分布式事务产生的一个案例。
那么如何解决事务问题，在学术上有一些理论知识，这里做个简单阐述。
二、ACID酸碱平衡理论
关系型数据库的ACID原理，这里对ACID做个简单的介绍。至于全面的ACID原理，请参考ACID
关系型数据库天生就是解决具有复杂事务场景的问题，完全满足ACID的特性。
数据库管理系统中事务(transaction)的四个特性（分析时根据首字母缩写依次解释）：
1.原子性（Atomicity） 原子性是指事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生
2.一致性（Consistency）一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性
3.隔离性（Isolation）多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。
4.持久性（Durability）这是最好理解的一个特性：持久性，意味着在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。（完成的事务是系统永久的部分，对系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持）
ACID属于刚性事务。强一致性。
三、CAP（帽子原理）
由于对系统或者数据进行了拆分，系统不再是单机系统，而是分布式系统，针对分布式系统的CAP原理包含如下三个元素。
C: Consistency,一致性。在分布式系统中的所有数据 备份，在同一时刻具有同样的值，所有节点在同一时刻读取的数据都是最新的数据副本。
A: Availability,可用性，好的响应性能。完全的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并进行响应。
P: Partition tolerance,分区容忍性。尽管网络上有部分消息丢失，但系统仍然可继续工作。
CAP原理是这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。
当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。
所以一般操作分布式事务是采用AP，即可用性，和分区容忍性。并通过消息最终一致性完成CAP。附上一张图：
四、经典分布式事务案例分析
支付案例特性：
1、可跨平台语言 2、操作较为麻烦 3、最基础解决方案
如图：通过回调接口通知来完成该事物，由于可以通过接口来控制，所以无论语言，数据最终通过JSON或XML进行解析即可。
但是操作会比较麻烦，做过支付相关的同学们应该就知道。所以支付案例其实就是一种类似于分布式事务的一种场景。
对它有个大致的了解，并且对理论有掌握后，解决这个问题就可以根据场景、需求、经验、实际情况等来选择最合适的方法了。
五、Base理论
前面说到刚性事务，也就是关系型数据库的特性。这里讲讲柔性事务，Base理论。
BASE理论是指，Basically Available（基本可用）、Soft-state（ 软状态/柔性事务）、Eventual Consistency（最终一致性）。
是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。
核心思想：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。
1、基本可用：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。比如：搜索引擎比如百度-0.5秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务等。
2、软状态：软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时。
3、最终一致性：
系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊情况。BASE理论面向的是大型高可用可扩展的分布式系统，通过牺牲强一致性来获得可用性。ACID是传统数据库常用的概念设计，追求强一致性模型。
总结：不论是哪种理论，都有它核心的思想，这里做个简述：
ACID：强一致性，不管性能消耗怎样，就是要求数据必须实时一致，硬性要求。
CAP：强调于做取舍，分区容忍性是基本要求（分布式），故可用性与一致性做取舍，通常是分区容忍性 + 可用性 最后通过最终一致性完成数据一致。
问题：看完CAP为啥不能三者权衡都用，一定要取舍？ 百思不得其解。答曰：由此衍生Base理论。
Base：存在软状态与最终一致性概念，所谓最终一致性，就是在一定时间内同步达到一致，并不是实施达到一致性，没有ACID那么刚性。适用于对一致性要求没那么高的分布式事务场景。但是不代表一定时间就很久，这个时间就是软状态，至于软多久，根据业务需求而定。