•2025年10月
systems

SQLite 与 CRDT 深度解析：值同步的实现原理

通过拆解 SQLite 中的增删改操作，详解 CRDT 如何利用版本时钟和墓碑机制，在本地优先的架构下实现无冲突的值同步与数据融合。

在构建本地优先（Local-First）的应用时，开发者面临的核心挑战之一是如何在多个离线客户端之间可靠地同步数据。当网络连接不可预测时，我们不再能依赖单一的中央服务器作为事实的唯一来源。SQLite 作为无处不在的嵌入式数据库，为本地存储提供了坚实的基础，但它本身并未解决分布式环境下的数据同步问题。此时，无冲突复制数据类型（CRDT）便成为了实现健壮、实时的值同步的关键技术。

本文将深入探讨将 CRDT 与 SQLite 集成的具体机制，重点剖析一个值的“增、删、改”操作如何在 CRDT 模型下被分解、追踪和合并，最终在无需中央协调的情况下实现多个数据库副本的强最终一致性。

捕获变更：从数据库触发器开始

一切始于用户与应用的交互，这些交互最终会转化为对 SQLite 数据库的 INSERT、UPDATE 或 DELETE 操作。要实现同步，第一步必须是精确捕获这些变更。一个高效且可靠的方法是利用 SQLite 的触发器（Triggers）。

通过在核心数据表上设置 AFTER INSERT、AFTER UPDATE 和 AFTER DELETE 触发器，我们可以构建一个不侵入业务逻辑的“钩子”。每当主表数据发生变化，这些触发器就会被激活，将变更的详细信息传递给同步引擎。这种方式的好处在于，同步逻辑与应用的核心 CRUD（创建、读取、更新、删除）逻辑完全解耦，使系统更易于维护。

解构变更：从行级到列级的原子操作

捕获到变更后，同步引擎并不能简单地将整行数据直接广播给其他节点。这样做会导致经典的“最后写入者获胜”（Last-Writer-Wins）问题，即并发修改同一行的不同部分时，后同步的修改会完全覆盖先同步的修改。例如，Alice 修改了任务的标题，而 Bob 同时修改了任务的状态。如果以行为单位进行同步，那么后到达的更新将覆盖前一个，导致其中一个用户的修改丢失。

CRDT 通过将变更的粒度从“行”降低到“列”来优雅地解决此问题。一次 INSERT 或 UPDATE 操作会被解构成一系列针对单个列的原子更新事件。

例如，一个 INSERT 操作：

INSERT INTO tasks (id, title, status) VALUES ('task-1', '购买牛奶', '未完成');

在 CRDT 引擎内部，这会被转化为三个独立的“列值设定”事件：

  1. 为 task-1 行的 title 列设置值为“购买牛奶”。
  2. 为 task-1 行的 status 列设置值为“未完成”。
  3. 为 task-1 行的 id 列设置值为“task-1”。

通过这种方式，Alice 对 title 的修改和 Bob 对 status 的修改就变成了两个互不干扰的独立操作，可以在合并时被同时保留，从而避免了冲突。

CRDT 日志：为每个值赋予因果历史

为了正确合并这些列级变更，我们需要一个地方来存储它们的历史记录和因果关系。这通常通过一个隐藏的“元数据表”或“CRDT 日志”来实现。表中的每一行都代表一次原子列值变更，并包含以下关键的元数据：

  • site_id: 变更来源的设备或节点的唯一标识符。
  • row_key: 变更所属行的主键，用于定位数据。
  • column_name: 变更发生的具体列名。
  • value: 列的新值。
  • column_version: 一个用于追踪因果关系的版本号，通常是兰伯特时钟（Lamport Clock）或混合逻辑时钟（HLC）。每次在同一设备上对同一列进行修改时，该时钟都会递增。
  • db_version: 数据库范围的逻辑时钟，用于高效地计算节点间需要同步的差异数据。
  • op_type: 操作类型，如 INSERT、UPDATE 或 DELETE。

当两个节点需要同步时，它们会交换各自已知的 db_version 信息，然后只发送对方缺失的日志条目。接收方在重放这些日志时，会根据 column_version 来解决真正的冲突——即两个节点同时修改了同一行的同一列。通用的解决策略是“保留版本号更高者”，由于逻辑时钟的特性，这保证了所有节点最终会收敛到相同的确定性状态。

特殊操作的处理：删除与墓碑机制

在分布式系统中，删除操作远比看起来复杂。如果一个节点直接从数据库中 DELETE 一行数据，而另一个离线的节点恰好在此时修改了这一行，当它们重新连接时，系统将无法判断“修改一个已删除的行”这一冲突。

CRDT 使用“墓碑”（Tombstone）机制来解决这个问题。当用户执行 DELETE 操作时，同步引擎并不会立即从物理上移除该行数据。相反，它会在 CRDT 日志中为该行（或其所有列）添加一个特殊标记，op_type 设为 DELETE。这个墓碑记录本身也带有版本号。

当其他节点同步到这个墓碑记录时，它们会检查其版本号。如果墓碑的版本号高于本地对该行任何列的修改版本号，那么该行就被标记为已删除（通常在应用层面隐藏）。这确保了删除操作的最终生效，并能正确处理与并发修改之间的冲突。墓碑记录通常需要保留一段时间，直到系统确认所有节点都已接收到该删除操作后，才能进行垃圾回收（GC）。

同步流程：从差异计算到状态融合

集成了以上机制后，两个节点（例如 Alice 和 Bob 的设备）之间的完整同步流程如下：

  1. 连接建立: Alice 和 Bob 的设备通过网络（P2P、WebSocket 服务器等）建立连接。
  2. 版本协商: Alice 向 Bob 发送她所拥有的每个 site_id 的最新 db_version。这构成了一个版本向量（Version Vector）。
  3. 差异计算: Bob 将 Alice 的版本向量与自己的进行比较，找出 Alice 缺失的所有 CRDT 日志条目（即 Bob 本地日志中 db_version 大于 Alice 已知版本的记录）。
  4. 数据传输: Bob 将这些差异日志条目打包发送给 Alice。
  5. 操作重放与合并: Alice 的同步引擎按因果顺序（通常由 db_version 和 seq 保证）重放接收到的日志。对于每一条变更：
    • 如果与本地变更冲突（同一行、同一列），则应用 column_version 更高的值。
    • 如果是不冲突的变更，则直接应用。
    • 如果是墓碑记录，则标记对应数据为已删除。
  6. 状态收敛: 完成重放后，Alice 的本地 SQLite 数据库状态就与 Bob 实现了融合。反向重复此过程，Bob 也拉取 Alice 的变更。最终，双方数据库将达到一致。

通过这种“列级追踪 + 因果时钟 + 墓碑删除”的机制，基于 SQLite 和 CRDT 的本地优先应用实现了强大的离线容错能力和无缝的数据同步体验，将复杂的分布式一致性问题，转化为一套稳健且可落地的工程实践。