分布式事务的理念
- 单体应用中的事务ACID
- 微服务中的分布式事务
- CAP理论 和 BASE理论
依据 CAP 理论，必须在可用性（availability）和一致性（consistency）之间做出选择。如果选择提供一致性需要付出在满足一致性之前阻塞其他并发访问的代价。这可能持续一个不确定的时间，尤其是在系统已经表现出高延迟时或者网络故障导致失去连接时。
- BASE 理论 ？
因为在微服务的架构中，不像单体应用哪样很容易就实现并且已经成熟，微服务中可能才用的都不是同类型的数据库，一般都是关系型数据库+ nosql 数据库 甚至有些图数据库、ES 等等。在这种情况下必然2PC的方案不能满足，因为XA条件限制。
2PC方案 ，分为准备提交+ 准备回滚2个分段。
###最佳实践微服务中采用最终一致性的方案
- CAP理论 和 BASE理论
- 可靠事件模式
举一个例子，客户下单，产出一个待支付订单，发送消息到mq ，支付服务进行消费订单服务，发送消息到mq 支付成功，订单服务消费 更新支付状态。
在这个例子中，请分析数据不一致的存在点，一个就是订单服务更新DB后，没有发送消息到mq。另外一点就是发送了多次的消息，支付服务如果进行处理，处理多次会导致数据不一致。
其中2点需要特别注意，保证消息投递的可靠性和避免重复消费，前者可以依靠mq本身特性，后者在业务中进行去重处理，保证幂等性。 - 业务补偿模式
补偿模式使用一个额外的协调服务来协调各个需要保证一致性的微服务，协调服务按顺序调用各个微服务，如果某个微服务调用异常（包括业务异常和技术异常）就取消之前所有已经调用成功的微服务。 - 业务异常
- 请在前置进行处理，能在validate 的情况下请避免。
- 技术异常
- 网络异常，非业务逻辑异常
补偿模式其实很繁琐，以为业务的调用链有时候过长，或者涉及到多个微服务，A-B-C-D 如果D 异常，需要在D当中处理反向的业务流程，也要保证最后的一致性问题。
- 网络异常，非业务逻辑异常
- TCC 模式
分成3个阶段，try 、commit、cancel 需要一个事务协调器，事务协调者也需要保证高可用，第一个阶段 发起事务到协调者，协调者 分别调用 其他服务进行锁定资源阶段，如果成功执行2阶段，如果失败业务失败。
第二阶段 根据第一阶段的结果，进行提交第一阶段锁定的资源或者进行回滚的操作。这个过程可能网络原因也会产生失败，要有一定的重试机制，幂等操作。