分布式系统中几种事务处理机制

事务简介：

本地事务：即为mysql数据库实现的事务，事务内的操作都在本节点内，且单个数据库，不会跨越多个节点，多个数据库。完全符合ACID特性。

分布式事务：指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。本质上来说，分布式事务就是为了保证在分布式场景下，事务中分散在多个节点数据操作的能够正确执行。

分布式事务类型：

刚性事务：遵循ACID中的强一致性，接近实时。要求事务中各个单元立刻提交或者回滚，没有时间弹性，以同步方式进行。用在分布式事务中最大的弊端就是影响性能，因为单个参与者不能自己提交事务，需要等待所有参与者执行ok才能一起提交，锁着时间变长。

柔性事务：不要求各个参与者同步执行，也不要求强一致性。只要满足基本可用和最终一致性就可以。

CAP理论：

• 一致性：分布式系统中的所有数据备份，任意同一时间都是一样的值。要求所有系统节点同步完成更新操作。
• 可用性：集群中一部分节点故障后，集群整体是否还能响应客户端的请求。更新高可用，同步下一个节点失败了（宕机），仍然能响应请求。（通过异步的后续操作完成同步）
• 分区容错性：在分布式系统中，一个请求要在系统中的多个节点完成，数据要在多个节点流转，所以天然存在分区。那就要具备一定的容错性，意味着系统在面对网络分区或部分节点失联的情况下，仍然能够提供服务，处理请求，而不是简单地拒绝服务或等待网络恢复。这通常涉及到一系列的策略和机制，比如数据复制、多数派决策、心跳监测等，来确保系统的健壮性和可靠性。分区容错性在分布式系统设计时必须考虑的一个点，保证了即使在网络不稳定或部分组件出现问题时，系统依然能够对外提供可靠的服务。

在分布式系统中，只能同时实现CAP中两点。分区容错性是基本的，只能在一致性或者可用性中取一个平衡。因为一般不需要强一致性，会牺牲一致性获取高可用。

BASE理论：

• 基本可用，basically available：分布式系统出现故障时，允许损失部分可用性，保证核心可用性。一般通过降级处理。
• 软状态，soft state：状态可在一定时间内不同步，允许延迟。也就是存在中间状态。
• 最终一致性，eventually consistent：弱一致性的一种特殊情况。允许系统中的所有数据副本一定时间后达到一致状态，不要求实时。牺牲强一致性，换得高可用性。
• 面向的是大型高可用可扩展的分布式系统，通过牺牲强一致性来获得可用性。

分布式事务解决方案：

1. 两阶段提交，2PC。刚性事务，它是强一致性的，在任何一个分布式阶段没有返回执行成功或失败的结果时，其事务一直会处于等待状态。并且2PC是利用DTP模型和XA规范，要求数据库支持XA规范，且通常都是在跨库的DB层面。适合银行，金融等对一致性要求比较高的场景。
2. TCC：属于两阶段提交的衍生版本，在应用层面做处理，需要通过自己编写逻辑代码来实现补偿。它的优势在于，可以让应用自己定义数据操作的粒度，使得降低锁冲突、提高吞吐量成为可能。而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。适合订单场景。

　　　　 TCC特点：

　　　　　　　并发度较高，无长期资源锁定

　　　　　　　开发量较大，需要提供Try/Confirm/Cancel接口

　　　　　　    一致性较好，不会发生SAGA已扣款最后又转账失败的情况

　　　　　　    TCC适用于订单类业务，对中间状态有约束的业务

　　　　  TCC分为三个阶段：

　　　　   　　try阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）。

　　　　　　　confirm阶段：确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 失败后需要进行重试，Confirm 接口要求具备幂等设计。

　　　　　　　cancel阶段：取消执行，释放 Try 阶段预留的业务资源。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致，cancel阶段要求满足幂等设计。

　　　　  TCC流程，和与2PC的区别：

　　　　                                       

• 最终一致性方案

  • 本地消息表。业界使用最多，核心思想就是将分布式事务拆成本地事务进行处理。与MQ事务消息的思路一样，都利用MQ通知不同的服务实现事务操作。不同的是针对消息队列的信任情况不同，本地消息表对消息队列的稳定性不信任，认为消息可能会丢失或者消息队列的运行出现阻塞，于是需要在数据库中建立一张独立的表，用于存放事务的执行状态，配合消息队列实现事务的控制。优点是避免了分布式事务，实现了最终一致性。缺点是消息表耦合的业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

  •  MQ事务消息 。有些MQ支持事务消息，如RocketMQ，ActiveMQ，支持事务消息的方式类似于二阶段提交，对消息队列比较信任，持乐观态度。Rabbitmq，kafka不支持。