最近因为工作的原因，涉及到分布式事务，只知道分布式事务是当今比较流行的，是基于微服务盛行的今天，分布式事务是必不可少的在我们的工作中。
实现分布式事务的几种方式：
1、基于数据库（操作简单）
2、基于zookeeper
3、基于redis的（效率高，现在大多数在用的）
大体知道这些，但是具体的更深入的就不太明白，所以今天就趁这个机会，上网搜索了一些资料，汇总了一些前辈的总结，来整明白分布式事务到底是什么，怎么用，再工作中如何实现。、
一：分布式事务的几个特性：
原子性 ，一致性，隔离性（独立性），持久性 （单机上）
二：对于集群的环境下：
需要引入几个新的理论原则来适应这种集群的情况，
1、就是 CAP 原则或者叫CAP定理，那么CAP定理指的是什么呢？
- 一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效)
- 可用性(Availability) ： 每个操作都必须以可预期的响应结束
- 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成
2、BASE理论
在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？ 前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：
- Basically Available（基本可用）
- Soft state（软状态）
- Eventually consistent（最终一致性）
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
三：实现分布式事务，无外乎那几种解决方案
1、两阶段提交（2PC）
优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）
缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景，如果分布式系统跨接口调用，目前 .NET 界还没有实现方案。
2、补偿事务（TCC）
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：
-
Try 阶段主要是对业务系统做检测及资源预留
-
Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
-
Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
-
优点： 跟2PC比起来，实现以及流程相对简单了一些（补偿事务较为简单一些），但数据的一致性比2PC也要差一些（补偿事务数据的一致性比2pc要相对差一些）
缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
3、本地消息表（异步确保）将分布式事务拆分成本地事务进行处理
优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。在 .NET中 有现成的解决方案。
缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理