IT评测·应用市场-qidao123.com技术社区

标题: 第三章:事务处理_《凤凰架构：构建可靠的大型分布式系统》 [打印本页]

---

作者: 祗疼妳一个    时间: 2025-4-8 01:23
标题: 第三章:事务处理_《凤凰架构：构建可靠的大型分布式系统》
第三章 事务处理

一、当地事务（3.1）

核心概念
当地事务指在单一数据库或资源管理器内完成的事务操作，依赖数据库的ACID特性保证数据划一性。
1. 原子性与持久性实现

• Undo Log（回滚日志）
  
  
  
  • 记载事务修改前的数据快照，用于事务失败时的回滚操作。
    
  • 通过日志的逆向操作恢复数据到事务前状态。
    
  
  
• Redo Log（重做日志）
  
  
  
  • 记载事务修改后的数据变更，确保事务提交后数据持久化。
    
  • 数据库崩溃恢复时，通过重做日志重新执行已提交的事务。
    
  
  

2. 隔离性实现

• 锁机制
  
  
  
  • 悲观锁：通过行锁、表锁等阻塞并发访问。
    
  • 乐观锁：基于版本号或时间戳检测冲突（如MVCC）。
    
  
  
• MVCC（多版本并发控制）
  
  
  
  • 通过保存数据的汗青版本，答应读操作不阻塞写操作。
    
  • 解决脏读、不可重复读题目，但大概产生幻读。
    
  
  

难点

• 隔离级别（如READ COMMITTED、REPEATABLE READ）对并发性能的影响。
  
• 幻读题目需通过间隙锁（Gap Lock）或串行化隔离级别解决。
  

---

二、全局事务（3.2）

核心概念
跨多个资源管理器（如多个数据库）的事务，依赖分布式事务协议（如XA协议）协调。
1. 两阶段提交（2PC）

• 阶段一：预备（Prepare）
  
  
  
  • 协调者询问所有参与者是否可提交，参与者锁定资源并返回预备就绪状态。
    
  
  
• 阶段二：提交/回滚（Commit/Rollback）
  
  
  
  • 若所有参与者同意提交，协调者发送提交指令；否则发送回滚指令。
    
  
  

题目

• 同步阻塞：参与者锁定资源期间，其他事务需等候。
  
• 单点故障：协调者宕机大概导致事务悬挂。
  
• 数据不划一：网络分区时大概部分提交、部分回滚。
  

2. 三阶段提交（3PC）

• 在2PC基础上引入超时机制和预提交阶段，降低阻塞风险。
  
• 新增阶段：CanCommit（询问可否提交） → PreCommit（预提交） → DoCommit（终极提交）。
  

对比2PC

• 长处：减少单点故障影响，降低阻塞概率。
  
• 缺点：实现复杂度更高，仍无法彻底解决数据不划一题目。
  

---

三、共享事务（3.3）

核心概念
在共享资源（如共享数据库毗连）场景下协调事务，常见于跨服务调用但共享同一数据库的情况。
实现方式

• 共享事务管理器
  
  
  
  • 通过单一事务管理器（如JTA）协调多个当地事务。
    
  
  
• 跨数据库事务
  
  
  
  • 使用分布式事务协议（如XA）实现跨数据库的原子性。
    
  
  

范围性

• 强依赖底层数据库的XA支持。
  
• 性能损耗大，扩展性差。
  

---

四、分布式事务（3.4）

核心挑战
在分布式系统中，CAP定理限定了同时满意划一性（C）、可用性（A）、分区容忍性（P）的大概。
1. CAP与ACID的关系

• ACID：强调事务的强划一性。
  
• CAP：分布式情况下需权衡划一性与可用性。
  
• BASE理论：通过终极划一性（Basically Available, Soft state, Eventually consistent）平衡CAP。
  

2. 可靠事件队列（3.4.2）

原理

• 通过消息队列保证事务操作的终极划一性。
  
• 生产者将操作记载为事件并持久化，消耗者异步处理。
  

实现步骤

• 当地事务与事件写入（保证原子性）。
  
• 消息队列投递事件（大概重试）。
  
• 消耗者处理事件并更新状态。
  

优缺点

• 长处：解耦服务，支持高可用。
  
• 缺点：需处理重复消息（幂等性），延迟较高。
  

3. TCC事务（3.4.3）

Try-Confirm-Cancel三阶段

• Try：预留资源（如冻结库存）。
  
• Confirm：提交确认（如扣减库存）。
  
• Cancel：赔偿回滚（如解冻库存）。
  

适用场景

• 对划一性要求高且业务逻辑可拆分的场景（如电商支付）。
  
• 需业务代码显式实现Try/Confirm/Cancel接口。
  

缺点

• 代码侵入性强，实现复杂度高。
  
• 需处理悬挂题目（如Try超时后Cancel未执行）。
  

4. SAGA事务（3.4.4）

原理

• 长事务拆分为多个当地事务，每个事务提供赔偿操作。
  
• 执行顺序：正向执行（如T1→T2→T3），失败时逆向赔偿（如C3→C2→C1）。
  

两种模式

• 协同式（Choreography）：无中央协调器，服务间通过事件触发。
  
• 编排式（Orchestration）：由中央协调器（如状态机）控制流程。
  

优缺点

• 长处：适合长事务，避免资源长期锁定。
  
• 缺点：赔偿逻辑复杂，大概产生“脏回滚”。
  

---

五、总结与对比

方案划一性性能复杂度适用场景2PC强划一低高传统金融、数据库集群可靠事件队列终极划一中中异步场景（如订单创建）TCC强划一中高高并发支付、库存管理SAGA终极划一高高长流程业务（如旅行预订） 关键结论

• 强划一性需求：优先考虑TCC或2PC，但需容忍性能损耗。
  
• 终极划一性场景：可靠事件队列或SAGA更符合。
  
• 无银弹：需根据业务特性（如延迟容忍度、回滚复杂度）选择方案。
  

多选题

---

题目1：关于当地事务的隔离性实现，哪些形貌正确？
A. 读未提交（Read Uncommitted）通过共享锁实现
B. 可重复读（Repeatable Read）通过多版本并发控制（MVCC）实现
C. 序列化（Serializable）通过范围锁（Range Lock）避免幻读
D. 读已提交（Read Committed）通过写锁（Exclusive Lock）保证数据划一性

---

题目2：两阶段提交（2PC）的范围性包括哪些？
A. 协调者单点故障大概导致事务阻塞
B. 事务参与者无法独立回滚当地操作
C. 网络分区大概导致数据不划一
D. 无法保证ACID中的原子性和持久性

---

题目3：关于CAP定理，哪些说法正确？
A. 分布式系统必须同时满意划一性和可用性
B. 分区容忍性（P）是必须保障的
C. 在发生网络分区时，系统可以临时牺牲划一性以保证可用性
D. ACID中的划一性（Consistency）与CAP中的C含义雷同

---

题目4：可靠事件队列模式的特点包括哪些？
A. 依赖消息队列的持久化保证
B. 必要业务逻辑实现幂等性
C. 事务终极划一性通过异步重试实现
D. 适用于强划一性要求的金融交易

---

题目5：TCC事务的三个阶段中，必须满意哪些条件？
A. Try阶段必要预留资源并锁定状态
B. Confirm和Cancel操作必须保证幂等性
C. Try阶段失败后直接回滚当地事务
D. Cancel阶段必要赔偿Try阶段的操作

---

题目6：SAGA事务的适用场景包括哪些？
A. 必要强划一性的订单支付流程
B. 长时间运行的跨服务业务流程
C. 每个子事务都有对应的赔偿操作
D. 支持部分提交和异步赔偿

---

题目7：关于分布式事务的赔偿机制，哪些形貌正确？
A. TCC的Cancel阶段是业务逻辑赔偿
B. SAGA的赔偿操作必须严酷顺序执行
C. 可靠事件队列通过消息重试实现自动赔偿
D. 所有赔偿操作必须保证幂等性

---

题目8：以下哪些场景大概导致全局事务的“悬挂”题目？
A. 两阶段提交中协调者宕机后恢复
B. TCC事务的Confirm阶段超时后重试
C. 可靠事件队列的消息重复消耗
D. SAGA事务的赔偿操作未正确回滚

---

题目9：关于事务的隔离级别，哪些形貌正确？
A. 读已提交（Read Committed）大概产生不可重复读
B. 可重复读（Repeatable Read）完全避免幻读
C. 序列化（Serializable）通过锁机制实现最高隔离性
D. 读未提交（Read Uncommitted）大概导致脏读

---

题目10：分布式事务中，哪些方法可以避免“脏写”？
A. 在TCC的Try阶段使用乐观锁
B. 可靠事件队列中采取唯一事务ID去重
C. SAGA事务通过赔偿操作回滚已提交的子事务
D. 两阶段提交（2PC）的第二阶段提交所有资源

---

---

答案与解析

题目1答案：B、C

• 解析：
  
  
  
  • B. 可重复读通过MVCC维护数据快照，保证同一事务内多次读取结果划一。
    
  • C. 序列化通过范围锁防止其他事务插入新数据（幻读）。
    
  • A错误：读未提交无需锁，直接读取未提交数据。D错误：读已提交通过行级锁保证当前读，但写锁与隔离级别无直接关联。
    
  
  

题目2答案：A、C

• 解析：
  
  
  
  • A. 协调者故障大概导致参与者长期阻塞。
    
  • C. 网络分区大概导致部分节点提交而其他节点未提交，数据不划一。
    
  • B错误：参与者可当地回滚。D错误：2PC保证原子性和持久性。
    
  
  

题目3答案：B、C

• 解析：
  
  
  
  • B. 分区容忍性是分布式系统的基础。
    
  • C. CAP中，在分区发生时需在C和A之间权衡。
    
  • A错误：CAP三者只能满意其二。D错误：ACID的C指业务规则束缚，CAP的C指数据划一性。
    
  
  

题目4答案：A、B、C

• 解析：
  
  
  
  • A. 消息队列需持久化防止消息丢失。
    
  • B. 消息大概重复，业务需幂等。
    
  • C. 异步重试确保终极划一性。
    
  • D错误：可靠事件队列适用终极划一性场景。
    
  
  

题目5答案：B、D

• 解析：
  
  
  
  • B. Confirm/Cancel需幂等以防止重复执行。
    
  • D. Cancel需回滚Try阶段的资源预留。
    
  • A错误：Try阶段仅预留资源，不锁定。C错误：Try失败后需触发Cancel。
    
  
  

题目6答案：B、C、D

• 解析：
  
  
  
  • B. SAGA适合长时间跨服务流程。
    
  • C/D. SAGA通过赔偿操作实现终极划一性，答应部分提交。
    
  • A错误：SAGA不保证强划一性。
    
  
  

题目7答案：A、C、D

• 解析：
  
  
  
  • A. TCC的Cancel是业务赔偿逻辑。
    
  • C. 可靠事件队列通过重试赔偿失败操作。
    
  • D. 所有赔偿需幂等。
    
  • B错误：SAGA赔偿可并行执行。
    
  
  

题目8答案：B、D

• 解析：
  
  
  
  • B. Confirm超时重试大概导致事务状态不划一。
    
  • D. 赔偿未正确执行大概导致部分提交。
    
  • A错误：协调者恢复后可继续流程。C错误：消息重复消耗由幂等性解决。
    
  
  

题目9答案：A、C、D

• 解析：
  
  
  
  • A. 读已提交大概不可重复读。
    
  • C. 序列化通过锁实现最高隔离。
    
  • D. 读未提交大概读到未提交数据。
    
  • B错误：可重复读大概仍有幻读（某些数据库破例，如MySQL InnoDB）。
    
  
  

题目10答案：A、B

• 解析：
  
  
  
  • A. 乐观锁防止并发写冲突。
    
  • B. 唯一ID去重避免重复处理。
    
  • C错误：SAGA无法回滚已提交的子事务。D错误：2PC第二阶段大概部分提交。
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/)

Powered by Discuz! X3.4