

首页  思维导图  详情



分布式事务解决方案

2023-08-14 11:21:53   6  举报





AI智能生成

分布式事务解决方案

分布式事务

模版推荐

作者其他创作

大纲/内容

数据库事务

ACID（更多指数据库事务层面）

Atomicity（原子性）

事务内的操作要么全部成功，要么全部失败，不会在中间的某个环节结束

Consistency（一致性）

数据库在一个事务执行之前和执行之后，都必须处于一致性状态，事务提交或执行失败，看到的结果一致

Isolation（隔离性）

并发环境中，不同事务同时修改相同数据时，一个未完成事务不会影响另外一个未完成事务

Durability（持久性）

事务一旦提交，其修改的数据将永久保存到数据库，改变是永久的

分布式事务理论

CAP理论

Consistency（一致性）

所有节点每次读操作都能保证获取最新数据，且一致。

Availability（可用性）

在集群中一部分节点故障后，集群整体还能响应客户端的读写请求，保证服务仍然可用

Partition tolerance（分区容错性，是分布式的基础）

网络节点之间无法通信的情况下，节点被隔离，产生了网络分区，整个系统仍然是可以工作的。简单理解，被分区的节点可用正常对外提供服务

BASE理论

Basically Available（基本可用）

Soft state（软状态）

Eventually consistent（最终一致性）

解决方案

两阶段提交（2PC）

阶段一（准备阶段）

1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复。

2、各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。

3、如参与者执行成功，给协调者反馈 yes，否则反馈 no。

阶段二（提交阶段）

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息。

存在的问题

性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。

可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。

数据一致性问题：在阶段 2 中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。

优缺点

优点

尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）

缺点

实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

具体实现

传统XA

Seata

第一阶段commit并记录undo日志

第二阶段提交或者回滚

三阶段提交（3PC）

阶段一（准备阶段）

1、协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。

2、参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

阶段二（预提交阶段）

协调者根据参与者响应情况，所有参与者均反馈 yes，协调者预执行事务。 只要有一个参与者反馈 no，或者等待超时后协调者尚无法收到所有提供者的反馈，即中断事务

阶段三（提交阶段）

进行真正的事务提交

优缺点

优点

相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题。阶段 3 中协调者出现问题时，参与者会继续提交事务

缺点

数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 do commite 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

补偿事务（TCC）

条件

需要实现确认和补偿逻辑，支持幂等

处理流程

1、Try 阶段主要是对业务系统做检测及资源预留。完成所有业务检查( 一致性 ) 。预留必须业务资源( 准隔离性 ) 。Try 尝试执行业务。

2、Confirm 阶段主要是对业务系统做确认提交。Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。

3、Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

优缺点

优点

1、性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。

2、数据最终一致性：基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。

3、可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。

缺点

TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本

异常处理

幂等处理

通过悲观锁与乐观锁保证数据的唯一性，确保幂等性

悲观锁

传统的关系型数据库使用这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 Java 里面的同步 synchronized 关键字的实现。悲观锁主要分为共享锁（读锁）和排他锁（写锁）

乐观锁

CAS 加版本号version，先查询再更新根据版本。使用条件限制实现乐观锁

空回滚

资源悬挂

可靠消息最终一致性

本地表

消息队列

Sagas事务模型（最终一致性）

拆分分布式事务为多个本地事务，由saga引擎负责协调，如果过程中出现部门失败，调用补偿操作。恢复策略：向前恢复和向后恢复，向前恢复对失败的节点采取最大努力不断重试，保证数据库的操作最终一定保证数据一致性，如果最终多次重试失败则根据相关日志主动通知开发人员手工介入。向后恢复对之前的成功节点执行回滚的事务操作，保证数据一致性。Saga比TCC少了Try操作，因此会直接提交数据库，然后出现失败进行补偿。

最大努力通知

方案一

通知接收方监听发送方mq，但mq并非和可靠消息最终一致性一样，没有ack就会一直推，而是根据规则推几次就不推了。但提供反查接口

方案二 

发送方通知程序监听自己队列，http协议发给消息接收方