第三章:事务处理_《凤凰架构：构建可靠的大型分布式系统》
第三章 事务处理一、当地事务（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企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]