分布式事务-基础理论

分布式事务产生的背景

分情况而定：
1、单体项目一个数据源中：多个不同业务逻辑都是在同一个数据源中实现事务管理，是不存在分布式事务的问题，因为同一数据源的情况下都是采用事务管理器，相当于每个事务管理器对应一个数据源。

2、单体项目多数据源中：，每个数据源中都有自己独立的事务管理器，互不影响，那么这时候也会存在多数据源事务管理（存在分布式事务）。解决方案：jta+ Atomikos，将每个独立的事务管理器统一交给atominc全局事务管理，性能较差。

3、在分布式/微服务架构中：每个服务都有自己的本地的事务，每个服务本地事务互不影响，那么这时候也会存在分布式事务的问题。调用方调用完服务方的接口的时候突然发生异常，自己的事务回滚了，但是服务方的事务无法回滚，会产生事务问题。
Rpc通讯中产生的分布式事务的问题原因：调用方调用完 rpc 接口之后，程序突然抛出异常，调用方的事务回滚了，但是被调用方接口没有回滚。被调用方的接口失败的话，调用方可以根据返回的结果，手动回滚调用方本地事务。

CAP和Base理论

这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性C：在分布式系统中，同一时刻所有的节点的数据都是相同的；
可用性A: 集群中部分节点出现了故障，集群的整体也能够给响应；
分区容错性P：分区容错性是指系统能够容忍节点之间的网络通信的故障，意味着发生了分区的情况，必须就当前操作在C和A之间做出选择；

BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写

BASE理论是基于CAP理论逐步演化而来的，是CP（强一致性）和AP（强可用性）权衡的结果。

BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点采用适当的方式来使系统达到最终一致性。

1. Basically Available（基本可用）
   响应时间上的损失：正常情况下，处理用户请求需要0.5s返回结果，但是由于系统出现故障，处理用户请求的时间变成3s。
   系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的非核心功能无法使用。

2. Soft state（软状态）
   数据同步允许一定的延迟。

3. Eventually consistent（最终一致性）
   系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，不要求实时。

总结：分布式系统中无法保证强一致性，因为数据短暂不一致时允许的，但是最终数据一定要保证一致性的问题。