【Java高阶面经：数据库篇】18、分布式事务：如何在分库分表中实现高性能与一致性？
一、分布式事务核心挑战：分库分表下的一致性困境
在分布式系统架构中，分库分表通过将数据分散存储提升了扩展性和性能，但却打破了传统单库事务的边界，使得分布式事务成为保障数据一致性的核心难题。其挑战主要体现在以下三方面：
1.1 ACID特性的分布式撕裂
- 原子性（Atomicity）：跨多个分片的操作需保证全部成功或回滚，如电商下单需同时操作订单库、库存库和支付库，任一环节失败需回滚所有已执行操作。
- 一致性（Consistency）：分库分表后，全局数据一致性需通过事务协调实现，例如用户余额扣减与订单状态更新需保持一致。
- 隔离性（Isolation）：高并发场景下，跨分片事务需避免脏读、幻读，如库存扣减时需防止其他事务看到中间状态。
- 持久性（Durability）：事务提交后数据需持久化，分布式环境下需确保多节点日志落盘成功。
1.2 分库分表的架构特殊性
- 数据分散性：事务操作可能涉及多个分片（如按用户ID分库的订单表与按SKU分库的库存表），需协调跨节点事务。
- 分片键影响：若事务涉及不同分片键（如用户ID和SKU ID），无法通过分片键路由到单一节点，强制跨库操作。
- 热点问题：高频事务可能集中在少数分片（如热销商品的库存分片），导致锁竞争加剧。
1.3 CAP定理的现实抉择
- 强一致性（CP）：牺牲可用性换取一致性，适用于金融交易等场景（如银行转账）。
- 最终一致性（AP）：牺牲强一致性换取高可用性，适用于电商下单、社交动态等场景。
- 分库分表场景下的权衡：多数业务选择最终一致性，通过异步补偿机制实现最终一致，同时保障性能。
二、分布式事务解决方案：从强一致到最终一致
2.1 两阶段提交（2PC）：强一致性的经典方案
2.1.1 核心流程
- 准备阶段（PreCommit）
- 协调者（Coordinator）向所有参与者（如订单库、库存库）发送事务请求，参与者执行事务操作（如扣减库存）但不提交，记录undo/redo日志，并返回“准备成功”或“失败”。