在构建跨多个数据库实例的业务系统时，开发者往往希望像操作单机数据库一样使用SQL事务，但现实情况要复杂得多。分布式事务要求多个独立节点上的数据变更保持原子性和一致性，而网络、节点状态和并发控制都会打破这种理想模型。理解这些困难的根源，需要从通信模型、协议设计和故障场景三个维度展开。
网络与故障模型带来的基础障碍
分布式系统首要面对的是网络不可靠。在单机事务中，应用程序和存储引擎通过共享内存或本地进程调用交互，失败概率极低。而在SQL分布式事务里，协调者向各个参与者发送提交或回滚指令，中间可能遭遇丢包、延迟剧增或分区。一旦网络在关键阶段中断，部分节点已经写入数据，另一部分节点还未知晓结果，系统就无法依靠本地逻辑自行决策。
节点宕机是另一类基础障碍。假设采用最常见的两阶段提交（2PC），若协调者在发出预写日志后、发送全局提交前崩溃，参与者们会停留在“已准备”状态，持有锁并阻塞后续事务。此时即使选举出新协调者，也需从持久化日志中推断之前的决定，若旧协调者日志未落盘，新协调者根本无从得知应提交还是回滚。这种不确定性直接违背了事务的隔离性直觉。
时钟漂移也会放大排查难度。很多团队试图用超时机制解除阻塞，但不同机器时钟偏移会导致错误的超时判断，例如参与者误以为协调者已死而自行回滚，随后协调者恢复并广播提交，造成永久不一致。因此SQL分布式事务不能简单套用单机超时逻辑，必须依赖外部协调服务或人工介入。
两阶段提交协议的实现代价
2PC是目前SQL分布式事务中最常被讨论的原子提交协议。第一阶段协调者询问所有参与者是否可以提交，参与者写本地undo/redo日志并锁定资源后返回就绪；第二阶段协调者根据反馈决定全局提交或中止，并通知参与者。从语义上看它弥补了跨节点原子性，但工程实现中暴露出明显短板。
同步阻塞是最突出的问题。在等待协调者第二阶段指令期间，参与者占用的行锁或表锁一直不释放，导致其他本地事务被挂起。高并发场景下，这种阻塞会沿着调用链扩散，引发雪崩。下面是一段简化的Java伪代码，展示参与者在就绪后被迫等待的状态：
// 参与者处理准备请求
public Response prepare(Transaction tx) {
writeRedoLog(tx);
lockResources(tx.getAffectedRows());
// 返回就绪，但锁仍持有
return Response.READY;
}
// 第二阶段到来前，其他线程尝试访问被锁资源会阻塞
public void otherBusiness() {
// 阻塞直到全局决定到达
acquireLock("row_1"); // 注意此处用中文引号描述，实际代码无引号
}
单点风险同样致命。协调者作为决策中枢，其可用性决定了整个事务系统的可用性。如果协调者无副本，一次宕机就使所有进行中的分布式事务停滞。引入主备协调者虽能缓解，但状态同步又引入新的一致性问题。此外，2PC无法完美处理参与者局部故障后的数据修复，常常需要补偿对账任务，增加了运维负担。
一致性与性能的权衡困境
业务方通常期望分布式事务提供和单机一样的强一致保证，但这与系统性能、可用性存在天然矛盾。追求强一致往往要求同步复制和严格隔离级别，使得每次SQL提交都伴随多次跨节点往返。与之相对，若采用最终一致模式，虽提升了吞吐，却要求应用层处理中间不一致状态，违背了使用SQL事务的初衷。
以跨行转账为例，源库扣款和目标库入账若放在一个分布式事务中，任何一环慢都会拖垮整体延迟。不少团队改用本地消息表加异步核对，把分布式事务拆成多个本地事务，但这已不属于传统SQL分布式事务范畴，而是业务补偿设计。下表对比了两类思路的差异：
| 方案 | 一致性 | 性能影响 | 实现复杂度 |
|---|---|---|---|
| 2PC强一致 | 即时全局一致 | 高延迟、易阻塞 | 协议与故障恢复复杂 |
| 本地事务加消息 | 最终一致 | 较低延迟 | 需补偿与对账逻辑 |
由此可见，SQL分布式事务的困难不仅来自技术协议本身，更来自业务对正确性与效率的双重期待。在真实架构中，往往需要根据场景放弃纯粹的透明事务，转而用显式编排降低系统脆弱性。只有认清这些边界，才能在多库环境下做出合理的技术选型。