技术深度解析
LiteFS通过在FUSE层拦截文件系统操作来实现分布式SQLite复制。当SQLite写入其WAL文件（通常为`-wal`）时，LiteFS捕获这些写入并将其复制到从节点。其关键洞察在于：SQLite的WAL已包含重建数据库状态所需的所有信息——LiteFS只需确保所有节点以相同顺序应用相同的WAL条目。
架构概览
LiteFS采用主-从拓扑结构。主节点运行一个FUSE守护进程，挂载一个虚拟文件系统。SQLite向该挂载点写入数据，LiteFS拦截写入系统调用。随后：
1. 捕获WAL帧：每次对WAL文件的写入都会被解析为单独的帧（页面）。
2. 分配全局序列号：使用类Raft共识协议，LiteFS为每批帧分配一个单调递增的序列号。
3. 复制到从节点：主节点通过gRPC流将这些帧发送到从节点。
4. 在从节点应用：从节点将帧写入本地WAL文件，然后检查点到主数据库文件。
关键的是，LiteFS并未为每次写入实现完整的Raft共识。相反，它采用一种轻量级的基于租约的机制：主节点持有一个必须定期续期的租约。如果主节点故障，从节点可以通过基于Raft的选举过程选举新的主节点。与完整的Raft复制相比，这种设计降低了每次写入的延迟开销。
FUSE性能开销
FUSE层为每次文件系统操作引入了用户空间与内核空间之间的上下文切换。对于LiteFS，这意味着每次SQLite写入都会产生：
- 从SQLite到FUSE内核模块的系统调用
- 切换到LiteFS用户空间守护进程的上下文切换
- 用于复制的网络I/O（如果写入发生在主节点）
- 切换回SQLite的上下文切换
LiteFS团队及独立测试的基准测试显示，与原生SQLite相比，性能特征如下：
| 工作负载 | 原生SQLite（WAL） | LiteFS（本地，无复制） | LiteFS（复制到1个从节点） |
|---|---|---|---|
| 只读（SELECT） | 100%基线 | 92-95% | 90-93% |
| 写密集型（INSERT） | 100%基线 | 60-75% | 40-55% |
| 混合（70/30读写比） | 100%基线 | 75-85% | 55-70% |
| 并发写入（10线程） | 100%基线 | 50-65% | 30-45% |
数据要点： FUSE开销在写密集型工作负载上最为显著，启用复制时LiteFS的吞吐量可能降低近一半。对于边缘应用典型的读密集型或混合工作负载，性能损失是可接受的（10-30%的降级）。
复制一致性模型
LiteFS提供两种一致性模式：
- 最终一致性（默认）：从节点可能落后主节点几毫秒。在WAL帧应用之前，从节点上的读取会返回过期数据。这适用于缓存、CDN边缘节点或对绝对新鲜度要求不高的分析场景。
- 强一致性（通过`litefs lease`）：应用可以请求主节点上的租约，确保所有后续读取都能看到最新的写入。这需要与主节点进行往返通信，从而增加延迟。
值得注意的是，LiteFS不支持分布式事务。如果应用需要在多个SQLite数据库（例如分片）之间进行原子写入，LiteFS无法提供帮助——每个数据库实例都是独立的。
相关开源仓库
- superfly/litefs（⭐4,766）：核心FUSE文件系统和复制守护进程。使用Go编写。截至2025年5月的最新提交包括WAL帧批处理的性能改进以及用于简化设置的`litefs mount`命令。
- superfly/litefs-example（⭐120）：展示如何将LiteFS与Ruby on Rails、Elixir/Phoenix和Go结合使用的示例应用。有助于理解部署模式。
- benbjohnson/litestream（⭐10,000+）：同一作者（Ben Johnson）的前身项目，专注于将SQLite复制流式传输到S3兼容存储。LiteFS基于Litestream的WAL捕获逻辑构建，但增加了实时集群复制。
关键参与者与案例研究
Superfly（Fly.io）
Superfly，即Fly.io背后的公司，创建LiteFS是为了解决一个特定问题：如何在其边缘计算平台上运行有状态应用。Fly.io在全球数据中心部署应用，许多客户希望使用SQLite的简洁性，同时需要跨区域故障转移。LiteFS于2023年开源，此后已被多个知名项目采用。
案例研究：边缘上的Rails
Ruby on Rails社区是早期采用者。Rails 7.1引入了`solid_cache`和`solid_queue`，两者均基于SQLite。LiteFS使这些组件能够跨多个Fly.io区域运行。例如，流行的Rails托管服务Hatchbox使用LiteFS为其客户提供多区域SQLite支持。性能报告显示，在典型Rails工作负载下，LiteFS的读写延迟增加在可接受范围内，同时显著提升了可用性。