传播行为、事务回滚、分布式事务（CAP理论和BASE理论）

1、事务回顾

事务：逻辑上的一组操作，组成这组操作的各个逻辑单元，要么都成功，要么都失败。
四大特征：ACID
并发问题：脏读、不可重复读、幻读
隔离级别：RU（Read Uncommitted）、RC（Read Committed）、RR（Repeatable Read）、SI（Serializable）

2、传播行为：

• 同一个service中的两个事务方法，传播行为不起作用，因为没有通过代理对象进行调用进而事务注解没起作用，导致传播行为无效。
  required：如果已存在事务则加入，否则新建
  requires_new：挂起当前事务，新建事务

3、事务回滚

• 所有的受检异常都不回滚（编译时异常 FileInputStream sleep）
• 所有的不受检异常都回滚（运行时异常 1/0）
• 自定义回滚策略：rollbackFor、rollbackForClassName
             noRollbackFor、noRollbackForClassName

4、分布式事务

4.1、分布式事务理论

• 逻辑上的一组操作，组成这组操作的各个逻辑单元在不同的服务、服务器上，要么都成功，要么都失败。
• 场景：工程 数据库
   不同工程 不同数据库
   不同工程 相同数据库
   相同工程 不同数据库
• 产生分布式事务因素：程序异常、网络问题、服务器故障等

4.1.1、CAP理论

4.1.1.1、CAP理论的基本概念

CAP理论是分布式系统设计中的一个重要理论，由Eric Brewer教授在2000年提出，并在2003年由MIT的Gilbert和Lynch正式证明。CAP理论指出，在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个特性不能同时成立，即在设计分布式系统时，通常需要在这三个特性之间做出权衡。

• 一致性（Consistency）：在分布式系统中，可能会在多个节点同时发生读写操作，在同一时刻所有节点拥有相同的值。
  1. 强一致性：时刻都一致
  2. 弱一致性：数据的同步有延迟
  3. 最终一致性：弱一致性的特殊情况
• 可用性（Availability）：系统必须保证在任何时刻都能够响应客户端的请求，即使部分节点或网络出现故障，系统也应该能够继续提供服务。
• 分区容错性（Partition Tolerance）：分布式系统必须能够容忍网络分区，即在网络分区发生时，系统仍然能够保持正常的工作状态，不会因为某个分区或节点的故障而导致整个系统不可用。

♣ 实际应用中无法同时满足CAP，要么满足AP（SpringCloud Mysql Redis），要么满足CP。
CAP理论是分布式系统设计中的一个重要理论，由Eric Brewer教授在2000年提出，并在2003年由MIT的Gilbert和Lynch正式证明。CAP理论指出，在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个特性不能同时成立，即在设计分布式系统时，通常需要在这三个特性之间做出权衡。

4.1.1.2、CAP理论的权衡

由于CAP理论指出分布式系统无法同时满足这三个特性，因此在设计系统时通常需要在它们之间做出权衡。常见的权衡方案包括：

• CA（一致性+可用性）：放弃分区容错性。这种方案适用于小规模、集中式系统，如传统的关系型数据库系统。然而，在分布式系统中，网络分区是不可避免的，因此这种方案在实际应用中较为少见。
• CP（一致性+分区容错性）：放弃可用性。这种方案适用于对数据一致性要求极高的系统，如金融交易系统。在这种方案中，当网络分区发生时，系统会暂停服务直到网络恢复，以保证数据的一致性。
• AP（可用性+分区容错性）：放弃一致性。这种方案适用于对数据实时性要求较高的系统，如社交网络等。在这种方案中，系统会在网络分区发生时继续提供服务，但可能返回不一致的数据。

4.1.1.3、CAP理论的应用场景

CAP理论的应用场景非常广泛，几乎涵盖了所有需要分布式系统支持的领域。例如：

• 金融系统：由于金融交易对数据一致性要求极高，因此通常会选择CP方案，以保证数据的一致性和分区容错性。
• 互联网服务：互联网服务对系统可用性的要求很高，因此通常会选择AP方案，以保证系统的可用性和分区容错性，同时接受一定程度的数据不一致性。
• 云计算平台：云计算平台需要同时处理大量用户的请求和数据，因此需要在CAP之间做出权衡，以满足不同用户和应用的需求。

4.1.1.4、CAP理论的启示

CAP理论告诉我们，在设计分布式系统时，需要根据具体的应用场景和需求来权衡一致性、可用性和分区容错性这三个特性。没有一种方案能够同时满足所有需求，因此需要根据实际情况做出合适的选择。同时，CAP理论也促进了分布式系统领域的发展和创新，推动了更多优秀分布式系统的出现。

4.1.2、BASE理论的基本概念

• 基本可用（Basically Available）：保证核心业务的可用性，允许部分不可用，不影响整体的可用性
• 软状态（Soft State）：又称中间状态，由旧状态到新状态之间，可能存在一定时间内的数据一致性。
• 最终一致性（Eventually Consistent）：不一致状态不可能一直维持，数据最终要保持一致。

♣ 保证核心业务可用，允许中间状态的出现，只要数据最终一致。

4.1.3、BASE理论与CAP理论的关系

• BASE理论是对CAP理论中一致性和可用性权衡的结果。CAP理论指出，一个分布式系统不可能同时满足一致性、可用性和分区容错性三个特性，而BASE理论则通过放宽一致性要求（采用最终一致性），来换取更高的可用性和灵活性。
• BASE理论更适用于大规模、高并发的分布式系统，如大型互联网应用、NoSQL数据库等。

综上所述，BASE理论为分布式系统设计提供了一种新的思路和方法，它强调在分布式系统中实现高可用性、灵活性和实时性的重要性，并通过放宽一致性要求来换取这些目标。

5、分布式事务解决方案

• 2PC：
   2代表两个阶段
   P：代表第一个阶段，Prepare准备阶段
   C：代表第二个阶段，Commit提交阶段
   ♣关系型数据库有基于2PC的XA协议：主流的关系型数据都实现了该协议。
   缺点：
    1.免费开源的数据库支持不够完善。
    2.需要多次网络通信，所以效率不高

• TCC（Try-Confirm-Cancel）事务：编程式分布式事务解决方案
  TCC事务分为三个阶段：Try、Confirm、Canel。
   Try阶段：预检资源并锁定资源，尝试执行，完成所有业务检查（一致性），预留必须业务资源（准隔离性）。
   Confirm阶段：执行业务操作，确认执行真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm操作要求具备幂等设计，Confirm失败后需要进行重试。
   Cancel阶段：取消事务或者补偿性事务，取消执行，释放Try阶段预留的业务资源。
   缺点：
    1.代码量大
    2.业务逻辑复杂的情况下，很难把握补偿点
    3.幂等性很难保证

• MQ（本地消息表）最终一致性：
  本地消息表的核心思想是将分布式事务拆分成本地事务进行处理。消息生产方需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，消息会经过消息队列发送到消息的消费方。
  特点：
   避免了分布式事务，实现了最终一致性。
   消息表会耦合到业务系统中，处理逻辑较为复杂。
  性能：MQ > TCC > 2PC
可靠性：2PC > TCC > MQ
简易：2PC > MQ > TCC