在分布式数据库架构中，如何在保持本地 SQLite 极低延迟读取优势的同时，实现与云端主数据库的实时数据同步，一直是边缘计算与本地优先应用的核心挑战。Turso 提出的嵌入式副本（Embedded Replicas）方案通过一套精心设计的帧 기반 同步协议，在文件系统层面捕获变更事件，再通过增量帧传播机制完成数据一致性维护。这一机制不仅解决了传统复制方案的高延迟问题，还为离线优先应用提供了可靠的技术基础。
帧机制：同步的基本原子单元
Turso 嵌入式副本的同步协议将数据变更拆分为离散的「帧」（Frame）作为传输单元。每一帧对应 SQLite 磁盘上的一个页面帧，大小固定为 4KB。这一设计源于 SQLite 本身的存储架构：无论是插入一行数据还是更新一个字节，只要该操作触发了页面修改，就会产生完整的 4KB 帧。这种固定粒度的设计在工程实现上具有显著优势。首先，帧的大小可预测使得网络传输和缓冲区管理变得简单可控；其次，4KB 与大多数文件系统的块大小对齐，能够充分利用操作系统的 IO 优化；最后，帧作为原子单元简化了冲突检测和断点续传的逻辑实现。
然而，这种固定粒度也带来了同步效率的权衡问题。当执行一次仅影响 1 字节的 UPDATE 操作时，协议仍然需要传输完整的 4KB 帧。从存储效率角度看这似乎存在浪费，但从协议复杂度和实现可靠性角度看，这种「宁多勿少」的策略确保了数据完整性。在 btree 结构因写入而发生节点分裂时，可能产生多个连续的帧，这种情况下同步的数据量会显著增加。服务端重启时如果磁盘上的 WAL 处于脏状态，协议会重新生成复制日志，导致额外帧的同步。工程团队在评估同步带宽成本时，需要将这些边界场景纳入考量。
WAL 集成：利用数据库日志捕获变更
Turso 同步协议的核心技术基础是 SQLite 的 Write-Ahead Log（WAL）机制。WAL 模式允许写入操作先追加到独立的日志文件而非直接修改主数据库文件，这种设计天然适合捕获增量变更。嵌入式副本通过监听 WAL 文件的变化来感知主数据库的写入事件，而非轮询数据库文件内容。这种基于日志的变更捕获方式具有极低的感知延迟 —— 当事务提交并写入 WAL 后，变更即可被同步协议捕获，无需等待检查点操作将变更落盘到主数据库文件。
在同步过程中，协议读取 WAL 中的页面帧并将其传输到本地副本。传输完成后，本地副本将应用这些帧到自身的 WAL 文件，随后通过 SQLite 的检查点机制合并到主数据库文件。这一流程确保了本地副本与主数据库的最终一致性。值得注意的是，由于 WAL 的顺序写入特性，同步协议可以采用流式传输方式处理大型事务的变更，避免了将整个事务加载到内存中的内存压力。对于每秒处理数千次写入的高频场景，这种流式处理能力至关重要。
同步策略：周期同步与按需同步
嵌入式副本支持两种同步模式：周期自动同步和手动触发同步。周期同步通过 syncInterval 参数配置，指定同步检查的时间间隔（单位为秒）。在服务器端部署场景中，通常建议将间隔设置为 60 秒或更短，以平衡网络开销与数据时效性。对于移动端或弱网络环境，可以适当延长间隔以减少电量消耗和流量使用。周期同步在后台静默执行，应用代码无需感知同步细节，即可获得相对新鲜的数据视图。
按需同步则通过显式调用 sync() 方法触发。这种模式适用于对数据时效性有严格要求的场景 —— 例如用户执行刷新操作后需要立即看到最新数据，或者在关键业务逻辑执行前需要确保本地副本与主数据库同步。两种模式可以组合使用：周期同步保证基础的数据新鲜度，按需同步处理用户的即时需求。协议在实现上对多次同步请求进行了合并优化，短时间内连续调用 sync() 不会产生冗余的网络请求。
读写语义：本地读取与远程写入的分离架构
嵌入式副本采用了读写分离的架构设计。读取操作始终在本地 SQLite 文件上执行，享受微秒级的查询延迟。这一设计使得应用可以完全屏蔽网络延迟的影响，提供丝滑的用户体验。当应用执行 SELECT 查询时，libSQL 客户端直接操作本地文件，无需任何网络往返。这种本地优先的读取策略是嵌入式副本的核心价值主张，也是其区别于传统远程数据库访问模式的关键所在。
写入操作的默认行为是将请求转发至远程主数据库（syncUrl 指定的地址）。这一设计确保了写入的全局可见性 —— 无论有多少个嵌入式副本存在，所有写入都汇聚到单一的数据源，避免了多主架构带来的冲突复杂性。写入成功后，协议会自动将变更同步回发起写入的本地副本，这就是「读己之所写」（Read Your Writes）语义的实现基础。发起写入的副本在写入返回后即可读取到刚写入的数据，无需额外的同步等待。对于其他副本，新数据将在下次同步周期或显式调用 sync() 时可见。
离线模式：本地写入的扩展支持
在标准配置下，写入操作需要网络连接才能完成。但 Turso 提供了 offline: true 配置选项来支持离线写入场景。启用离线模式后，写入操作首先在本地副本执行，待网络恢复后再异步同步到主数据库。这种模式对于移动应用和边缘设备具有重要意义 —— 用户可以在完全离线的状态下继续使用应用，数据变更暂存本地，连接恢复后自动完成同步。
离线模式下的写入同步面临的主要挑战是冲突解决。当用户在离线期间修改了数据，而服务器端同一记录也发生了变更时，就会产生同步冲突。Turso 的协议采用了「最后写入者获胜」（Last Writer Wins）的冲突解决策略，时间戳由服务器端判定以确保全局一致性。这种策略虽然简单但有效，避免了复杂的应用层冲突处理逻辑。对于业务层面需要更精细冲突处理的场景，应用开发者需要在写入前实现自己的乐观锁机制或版本检查逻辑。
工程实践要点
在生产环境中部署嵌入式副本时，有几个关键注意事项需要牢记。首先，在同步进行期间不应打开本地数据库文件 —— 这可能导致数据损坏，因为 SQLite 正在执行页面替换操作。其次，嵌入式副本依赖文件系统可用性，因此不适用于无状态的 serverless 环境（如某些云函数的执行模型）。对于这类场景，需要采用 Turso 的边缘网络副本而非嵌入式副本方案。
监控层面建议关注同步延迟指标和帧传输量。同步延迟反映了本地副本与主数据库之间的数据新鲜程度，对于时间敏感的应用应设置告警阈值。帧传输量的异常增长可能指示 btree 结构问题或频繁的服务端重启，需要进一步诊断。加密方面，嵌入式副本支持通过 encryptionKey 参数启用存储加密，确保本地文件的静态安全。加密密钥的管理应遵循密钥管理最佳实践，避免硬编码或明文存储。
资料来源：Turso 官方文档关于嵌入式副本的介绍与 API 说明。