当前位置：首页 > news >正文

详细分析分布式事务场景、理论基础以及解决方法

news 2024/11/11 5:22:29

前言

原先的基本知识：数据库关于事务的详解分析（全）包含面试常问的细节

分布式事务是指在多个不同的服务或系统中执行的事务，涉及多个数据库或资源的协调，以确保所有的操作都要么全部成功，要么全部失败，保证数据的一致性。

分布式事务主要用于微服务架构、跨数据库的操作、以及涉及多个第三方系统的业务流程中

1. 分布式事务场景

基本的场景如下：

一、微服务间的事务
在微服务架构中，业务逻辑通常分布在多个服务中。一个典型场景是一个业务操作需要在多个微服务中执行不同的操作

电商系统的订单服务、库存服务、支付服务需要协调操作：创建订单，扣减库存，处理支付
在跨多个服务的操作中，数据的一致性成为问题，如果一个服务的操作成功而另一个服务失败，可能导致数据不一致

二、跨数据库的事务
在一些场景中，应用可能需要对多个数据库（甚至是不同类型的数据库）进行操作

企业级系统中，订单信息存储在MySQL中，而财务信息存储在Oracle中，订单创建和支付处理需要操作两个数据库
这种场景下，如果一个数据库操作成功，另一个失败，则会产生数据不一致问题

三、第三方系统集成
某些场景下，系统需要与第三方系统进行交互

银行转账系统需要协调银行A和银行B的操作，确保资金转出和转入的操作一致
电商平台集成第三方支付平台时，涉及订单创建与支付确认的分布式事务

2. 理论基础

一、ACID
传统事务理论中的ACID属性（Atomicity、Consistency、Isolation、Durability）定义了事务的一致性要求：

原子性 (Atomicity)：事务的所有操作要么全部成功，要么全部回滚
一致性 (Consistency)：事务执行前后，数据必须处于一致状态
隔离性 (Isolation)：并发事务之间互相隔离，避免相互影响
持久性 (Durability)：一旦事务提交，数据的更改将永久保存

在单一数据库系统中，ACID通常由数据库管理系统（DBMS）来保证，但在分布式系统中，由于涉及多个节点或数据库，ACID难以直接应用

二、CAP定理
CAP定理指出在一个分布式系统中，不可能同时保证以下三者：

一致性 (Consistency)：所有节点都在同一时间看到相同的数据
可用性 (Availability)：每个请求都能收到一个响应（无论成功或失败）
分区容忍性 (Partition tolerance)：系统能在部分网络节点失效的情况下继续运行

根据CAP定理，在分布式系统中，设计事务时通常需要在一致性、可用性和分区容忍性之间进行权衡

三、BASE理论
BASE理论是对CAP定理的一种延伸，用于描述在分布式系统中的事务一致性策略：

基本可用 (Basically Available)：系统在大部分时间是可用的，允许部分功能失效
软状态 (Soft state)：系统状态可能是中间状态，并不会立即一致
最终一致性 (Eventually consistent)：经过一段时间，所有节点最终会达到一致性

BASE理论强调的是分布式系统中的"最终一致性"而非强一致性，允许系统在短暂的时间内出现数据不一致

3. 解决方法

分布式事务在分布式系统中的核心挑战是如何确保多个服务、数据库或系统之间的一致性和原子性。以下是几种常见的分布式事务解决方案的详细阐述，包括它们的工作原理、优缺点以及适用场景

一、两阶段提交（2PC，Two-Phase Commit）

工作原理：
两阶段提交是一种经典的分布式事务协议，它确保多个参与者在执行事务时，能以一致的方式提交或回滚事务
2PC协议分为两个阶段：

准备阶段（Prepare Phase）：
事务协调者（Coordinator）向所有参与者（Participants）发送准备提交的请求
每个参与者接收到请求后，执行本地事务并暂时不提交，同时返回一个"准备好"或"失败"的响应给协调者
提交阶段（Commit Phase）：
如果所有参与者都返回了"准备好"，协调者发送“提交”请求，所有参与者提交本地事务
如果有一个或多个参与者返回"失败"，协调者发送“回滚”请求，所有参与者回滚本地事务

优点：
强一致性：确保事务要么全部提交，要么全部回滚，保证数据一致性
简单易于理解：流程较为简单，容易实现和部署

缺点：
性能问题：在准备阶段，参与者锁定资源直到提交完成，可能导致长时间锁定，影响系统性能
单点故障问题：如果协调者在准备阶段崩溃，系统可能会处于不确定状态，导致资源被长时间锁定
阻塞性：参与者在等待协调者的指令时，无法释放锁，容易造成阻塞

适用场景：适用于需要强一致性且事务量较小的场景，如跨多个数据库的操作或传统的企业级应用系统

三阶段提交（3PC，Three-Phase Commit）

工作原理：
三阶段提交是对两阶段提交的改进，通过引入超时和预提交机制，减少了阻塞和单点故障的影响
它将2PC中的提交阶段拆分为两个阶段，总共分为三个阶段：

CanCommit阶段：
协调者询问所有参与者是否可以提交事务，即发出“CanCommit”请求
参与者根据本地情况决定是否可以继续，并返回响应
PreCommit阶段：
如果所有参与者都同意继续，协调者进入预提交阶段，向参与者发出“预提交”命令，参与者将事务置于准备提交状态，但仍未提交
参与者在预提交状态下等待最终的提交指令，同时锁定资源
DoCommit阶段：
如果所有参与者成功进入预提交状态，协调者发出最终的“提交”请求，所有参与者提交事务
如果任何参与者在超时前没有响应，或某个参与者返回失败，协调者可以发送“回滚”命令，所有参与者回滚事务

优点：
非阻塞性：引入超时机制后，即使协调者或参与者发生故障，系统也能自动进行超时处理
减少单点故障影响：通过增加CanCommit和PreCommit阶段，系统可以在某些故障情况下自动恢复或采取补救措施

缺点：
流程复杂：相比2PC，三阶段提交协议增加了通信的复杂性和网络延迟
依然有性能开销：虽然改善了阻塞问题，但依然需要多次网络交互，整体性能开销较大

适用场景：适用于对一致性要求高但能够容忍一定的性能开销的场景，如金融系统中的多方资金转账等

TCC（Try-Confirm-Cancel）模式

工作原理：
TCC是一种基于补偿机制的事务管理方式，将每个事务操作分为三步：Try（预留资源）、Confirm（确认提交）、Cancel（取消回滚）。每个参与者都必须实现这三步操作

Try阶段：在Try阶段，参与者预留资源或进行初步检查，确保业务操作能够成功（例如冻结资金或锁定库存）
Confirm阶段：在Confirm阶段，参与者实际执行提交操作。如果所有参与者的Try操作成功，事务协调者发起Confirm请求，所有参与者确认并提交事务
Cancel阶段：如果Try阶段的某些操作失败，事务协调者发起Cancel请求，所有参与者执行回滚操作，撤销之前的预留资源

优点：
减少锁定时间：在Try阶段并不真正提交数据，因此避免了长时间的锁定问题，性能更高
灵活性强：适用于各种复杂的业务场景，允许开发者定义特定的Try、Confirm、Cancel逻辑

缺点：
实现复杂：开发者必须为每个操作定义三步逻辑，增加了开发和维护的复杂性
适用性有限：某些场景下（如不允许预留资源或无法定义合适的补偿机制），TCC难以应用

适用场景：适用于微服务架构中需要较高并发性能的场景，如电商系统中的订单、库存、支付协调

本地事务+事件驱动（基于事件的最终一致性）

工作原理：
本地事务+事件驱动的模式使用事件消息机制将分布式事务分解为多个独立的本地事务，各服务通过消息队列或事件总线进行异步通信，确保最终一致性。

每个服务执行本地事务：每个服务只需确保自身本地事务的成功执行，而不直接管理全局事务
发布事件：事务执行成功后，服务发布事件到消息队列或事件总线，通知其他相关服务
事件消费者执行后续操作：消费者服务接收事件并执行相应的操作，确保系统最终达到一致状态
补偿机制：如果某个服务操作失败，可以通过发布补偿事件或重新执行来进行数据回滚或补偿

优点：
高性能：各个服务间松耦合，异步操作极大提升了系统性能，适合高并发场景
灵活性高：适用于微服务架构，不依赖强一致性，可以根据业务需求灵活调整一致性策略

缺点：
最终一致性：无法保证强一致性，系统中会存在短暂的不一致时间
复杂的错误处理：需要处理消息丢失、重复消费等问题，且补偿逻辑复杂

适用场景：适合对强一致性要求不高的场景，如社交媒体系统、电商系统的订单处理等，强调性能和可用性优先

模式	优点	缺点	适用场景
两阶段提交	强一致性，简单易懂	性能差，阻塞问题严重，单点故障风险	需要强一致性的传统系统
三阶段提交	改善阻塞和单点故障问题，引入超时机制	实现复杂，网络延迟大时效果不佳	金融类系统，需要高一致性但容忍延迟
TCC	高性能，灵活性强，减少长时间锁定资源	实现复杂，开发成本高	微服务架构中的高并发场景
事件驱动	性能优越，异步处理，松耦合	只保证最终一致性，补偿逻辑复杂	对一致性要求不高，追求高可用性场景