详见6.8小节
柔性事务主要分为补偿型和通知型，
补偿型事务又分：TCC、Saga；
通知型事务分：MQ事务消息、最大努力通知型。
TCC其实本质和3 PC是差不多的：
- T就是Try，两个C分别是Confirm和Cancel。
- Try就是尝试，请求链路中每个参与者依次执行Try逻辑，如果都成功，就再执行Confirm逻辑，如果有失败，就执行Cancel逻辑。
-
柔性事务概述
柔性事务是相对于传统的刚性事务而言的一种事务处理机制。刚性事务遵循 ACID（原子性、一致性、隔离性、持久性）原则，适用于单数据库系统等场景，能严格保证事务的正确性和数据的一致性。而柔性事务主要用于分布式系统环境，在这种环境下，严格遵循 ACID 原则会带来性能下降、可用性降低等问题。柔性事务通过放宽对 ACID 某些特性的要求，同时采用补偿机制等手段来确保分布式系统在高并发、高可用等复杂场景下数据的最终一致性。
-
柔性事务的常见模式
-
补偿事务（Compensating Transaction）
- 定义：补偿事务是一种事后补偿的机制。当一个分布式事务中的某个操作（或一组操作）失败时，通过执行一个与之相对应的补偿操作来撤销之前已经执行成功的部分操作，从而达到最终的一致性。例如，在一个电商系统中，当订单创建成功后需要调用库存系统扣减库存，如果库存扣减失败，就需要执行一个补偿操作，如将已经创建的订单状态修改为无效，以保证系统数据的一致性。
- 工作流程：首先，事务开始执行各个子事务（可以是不同服务或数据库中的操作），每个子事务在执行过程中记录必要的业务信息（如操作日志、上下文信息等）。当某个子事务失败时，系统根据之前记录的信息触发补偿事务。补偿事务会按照预定的规则和业务逻辑，对已经成功执行的子事务进行反向操作。
-
TCC 事务（Try - Confirm - Cancel） 《Life beyond Distributed Transactions:an Apostate’s Opinion》
- 定义：TCC 是一种更细粒度的柔性事务模式。它将事务分为三个阶段：Try（尝试）、Confirm（确认）和 Cancel（取消）。在 Try 阶段，业务系统进行资源的预留（如冻结资金、锁定库存等），但不进行实际的业务操作。如果 Try 阶段所有操作都成功，就进入 Confirm 阶段，此时对之前预留的资源进行真正的业务处理（如扣除资金、扣减库存等）。如果在 Try 阶段有任何操作失败，就进入 Cancel 阶段，释放之前预留的资源。
- 工作流程：以一个在线支付场景为例，在 Try 阶段，支付系统会冻结用户账户中的相应金额，同时订单系统会锁定商品库存。如果这些操作都成功，就进入 Confirm 阶段，支付系统扣除冻结的金额，订单系统扣减锁定的库存，完成订单交易。如果在 Try 阶段，例如库存锁定失败，就进入 Cancel 阶段，支付系统解冻之前冻结的金额，取消本次交易。
-
基于消息的最终一致性（Message - Based Eventually Consistent）（即通知型）
- 定义：这种模式利用消息中间件来实现分布式事务的最终一致性。在分布式系统中，当一个业务操作完成后，通过发送消息到消息中间件来通知其他相关的业务系统进行后续操作。消息的发送和接收是异步的，接收消息的系统可能会因为网络延迟、系统故障等原因不能立即处理消息，但最终会在系统恢复正常后处理消息，从而达到数据的最终一致性。
- 工作流程：例如，在一个电商系统中，当用户下单成功后，订单系统会发送一个消息到消息中间件，通知库存系统和物流系统。库存系统收到消息后进行库存扣减，物流系统收到消息后安排发货。如果库存系统或物流系统在收到消息时出现故障，消息中间件会保留消息，直到系统恢复正常后重新发送消息，确保各个业务系统的数据最终达到一致。
-
柔性事务的应用场景和优势
-
应用场景
- 微服务架构：在微服务架构中，不同的微服务可能使用不同的数据库，并且服务之间的调用通过网络进行。柔性事务能够适应这种分布式、异构的环境，保证跨微服务的业务操作最终达到数据一致性。
- 高并发系统：对于高并发的电商、金融等系统，严格的刚性事务可能会因为锁机制等导致性能瓶颈。柔性事务通过异步操作、补偿机制等方式，可以在保证数据最终一致性的前提下，提高系统的并发处理能力。
-
优势
- 提高系统可用性：与刚性事务相比，柔性事务不会因为某个子事务的短暂故障（如网络抖动、某个服务的临时不可用）而导致整个事务失败，通过补偿机制或异步处理可以继续完成事务，从而提高了系统的可用性。
- 提升性能：避免了刚性事务中大量的同步等待和锁竞争，例如在 TCC 事务的 Try 阶段只是进行资源预留，不像刚性事务那样直接进行资源的占有和操作，减少了对系统资源的占用，提升了系统的性能。
...