引言

在构建分布式系统时，保证数据一致性是一个核心挑战。当业务流程需要跨越多个服务或数据源时，简单的本地事务不再足够。本文将探讨分布式事务管理中的两种主要模式——Saga 和两阶段提交(2PC)，以及在使用 SQLite 等嵌入式数据库时面临的特殊挑战。

Saga 模式：最终一致性的权衡

Saga 模式是一种分布式事务管理的设计模式，它将一个大型事务分解为多个小型本地事务，并通过补偿机制来保证最终一致性。

Saga 的工作原理

1. 将分布式事务拆分为一系列本地事务
2. 每个本地事务完成后发布事件或由协调器触发下一步
3. 如果任何步骤失败，执行补偿事务来撤销之前的操作

Saga 的关键问题：数据可见性

然而，Saga 模式面临一个重要挑战：数据可见性问题。当一个本地事务提交后，其变更立即对外部可见，这可能导致：

• 客户端可能读取到中间状态的数据（“脏读”）
• 在补偿操作完成前，系统处于不一致状态
• 业务决策可能基于尚未最终确认的数据

这种情况下，系统只能保证最终一致性，而非实时的强一致性。对于某些业务场景，这种不确定性可能无法接受。

两阶段提交(2PC)：追求强一致性

为了解决 Saga 模式中的数据可见性问题，我们可能会考虑使用两阶段提交(2PC)协议。

2PC 的工作原理

1. 准备阶段：协调者要求所有参与者准备提交事务，参与者执行事务但不提交，锁定相关资源
2. 提交阶段：如果所有参与者都准备好，协调者通知所有参与者提交；否则通知所有参与者回滚

2PC 的主要优势在于它能提供强一致性保证——所有参与者要么全部提交，要么全部回滚，且在事务完成前，变更对外部不可见。

SQLite 的局限性：文件级锁定的困境

然而，当我们尝试在使用 SQLite 的系统中实现 2PC 时，会遇到一个根本性的限制：SQLite 使用文件级锁定机制。

SQLite 的锁定特性

• SQLite 使用整个数据库文件级别的锁
• 同一时间只允许一个写操作
• 不支持行级或表级锁定
• 不支持保持"准备好但未提交"的中间状态

为什么 SQLite 不适合 2PC？

2PC 要求参与者能够：

1. 在准备阶段锁定资源但不提交变更
2. 支持 XA 等分布式事务协议
3. 允许多个参与者同时处于准备状态

SQLite 的设计与这些要求根本不兼容。它不支持 XA 协议，无法维持"准备好"的中间状态，也不允许多个连接同时获取写锁。

解决方案与权衡

面对这一困境，我们有几种可能的解决方案：

1. 接受 Saga 模式的局限性

如果业务可以容忍短暂的不一致状态，可以使用 Saga 模式并通过以下方式减轻数据可见性问题：

• 使用状态标记区分中间状态和最终状态
• 实现查询隔离，默认只返回已完成事务的数据
• 采用 CQRS 模式分离读写操作

2. 更换数据库系统

如果业务确实需要强一致性保证：

• 迁移到支持分布式事务的数据库（如 PostgreSQL、MySQL 等）
• 使用支持 XA 协议的嵌入式数据库（如 H2）

3. 重新设计系统架构

• 简化业务流程，减少跨服务事务的需求
• 使用事件溯源模式记录所有状态变更
• 采用状态机设计明确表达业务流程的各个阶段

结论

分布式事务管理是一个复杂的技术挑战，需要在一致性、可用性和性能之间做出权衡。Saga 模式提供了最终一致性但面临数据可见性问题；2PC 提供了强一致性但增加了复杂性和性能开销；而 SQLite 等嵌入式数据库由于其架构设计，对分布式事务的支持存在根本性限制。

在选择解决方案时，我们需要深入理解业务需求和技术限制，找到最适合特定场景的平衡点。有时，这可能意味着接受某些限制，或者重新思考系统架构和技术选型。

无论选择哪种方案，清晰理解其优缺点和适用场景，对于构建可靠的分布式系统至关重要。