Twelve years of distributed SQLite

十二年分布式 SQLite 之路 – Philip O'Toole

十二年分布式 SQLite 之路

• Philip O'Toole

• 2026年10月23日

• 未分类

• 3条评论

2014年9月我发布了一篇短文宣布推出 rqlite。这个想法很简单：将 SQLite 与 Raft 日志结合，在集群中复制所有写入操作，使得单个节点失效时数据也不会丢失。那个周末代码就上传到了 GitHub。据我所知，这是首个将 Raft 与 SQLite 结合的开源系统。当时没有其他人尝试，此后几年也没有人跟进。

如今"分布式 SQLite"已成为一个包含十余个项目的类别，其中几个获得了风投，两个被收购。由于现在讨论这个领域的人往往从2021年开始讲述故事，我认为有必要记录下从2014年开始的完整版本。我亲历了整个发展过程。

2014：rqlite 的诞生

需求非常明确。我在 jut.io 工作时开发的集群系统需要少量关系型存储，但关于哪个节点应该保存数据却没有明确答案。通过共识协议复制 SQLite 解决了这个问题。虽然工作中我们选择了其他方案，但我持续开发 rqlite，因为这个问题具有普遍性，而解决方案却很简洁。首个版本使用了 goraft 库（当时 InfluxDB 和 etcd 也使用该库，之后我加入了 InfluxDB 并成为核心开发者）。2016年初我将其替换为 Hashicorp 的 Raft 实现，这也是 rqlite 当前仍在使用的方案。

最关键的设计决策在当时就已确定且从未改变。rqlite 是一个 CP 系统。所有写入必须经过领导者节点，需要多数节点确认，分区后的少数节点会拒绝写入。其他所有特性——HTTP API、读取一致性级别、快照功能——都由此衍生。

2014年前及同期

出于诚实，有两件事需要提及。Expensify 多年来一直在其基础设施中使用类似 Paxos 的协议复制 SQLite，他们在2016年将其作为 Bedrock 发布。同时期还出现了 ActorDB——一个使用 Erlang 的系统，为每个"actor"分配独立的 SQLite 数据库并通过 Raft 复制。这些项目虽然在其发源地之外并未广泛采用，但都表明这个想法当时已在业界酝酿。rqlite 的突破在于将其打造成了任何人都可以使用的独立、通用、开源解决方案。

2017：dqlite 的出现

Canonical 开发 dqlite 的目的是为 LXD 和后来的 MicroK8s 提供一个无需运行 etcd 的嵌入式复制存储。Mark Shuttleworth 曾经亲自联系过我，我们讨论过是否能让 rqlite 适配他们的需求，但始终没有完全契合。dqlite 最初用 Go 语言开发，后来改用 C 语言并使用了自研的 Raft 库。这是与 rqlite 意图最相似的项目，主要区别在于封装方式：dqlite 是一个需要嵌入的库，而 rqlite 是一个需要运行的服务器。Canonical 的需求是将其集成到产品内部，而我的目标是打造一个可以与任何产品并行使用的数据库。

Ben Johnson（我在InfluxDB共事的同事）于2021年初发布了Litestream。Litestream完全不使用共识机制。它监控SQLite的WAL文件并将其流式传输到S3，几乎以零成本为单节点SQLite数据库提供灾难恢复能力。Ben的论点是，大多数应用程序并不需要集群；它们使用单台机器，并需要一种在机器故障时恢复的方法。他对于许多应用程序的判断是正确的，接下来几年"SQLite已经足够"的运动（包括博客文章和会议演讲）很大程度上归功于这一论点。

Litestream和rqlite回答的是不同的问题。Litestream：如果机器宕机怎么办？rqlite：如果机器宕机且无法等待恢复怎么办？第一个问题更为常见，而第二个问题正是人们转向rqlite时所面临的问题。

Fly.io于2022年雇佣了Ben并推出了LiteFS，该产品通过Consul的租约在文件系统层面实现SQLite复制。这是首次尝试将复制SQLite作为平台特性而非部署组件来实现。最后的转折是，Litestream启发了rqlite在v8.0版本中对SQLite WAL的处理方式。

2022：分叉与扩展

2022年有两个项目采用了rqlite和Litestream都没有使用的方法。cr-sqlite作为SQLite的扩展添加了CRDTs，使多个写入者可以在没有领导者的情况下实现数据分歧和合并。这是设计空间中AP（最终一致性）的角落，适合需要本地优先的场景，而rqlite的CP（强一致性）保证会成为阻碍。

libSQL直接分叉了SQLite本身。ChiselStrike（后来的Turso）希望改变SQLite引擎内部的实现，而SQLite项目本身不接受外部贡献且不会做出更改。在分叉基础上，他们构建了边缘节点带有副本的托管服务。Turso基于此模式获得了风险投资，2026年Supabase收购了他们。

同期出现了SQLite Cloud，提供基于Raft的托管SQLite复制服务。这是与rqlite原始设计最接近的项目，只不过被包装成了云服务。

2022年及以后：平台化

Cloudflare于2022年宣布了D1，这是其边缘网络内的SQLite无服务器数据库，后来又将SQLite存储集成到Durable Objects中。这是由不需要解释实现细节的公司提供的托管复制SQLite产品。Turso的服务模式与之相同。该领域已从"需要运行的组件"转变为"需要购买的产品"。

十二年的启示

我认为有三件事值得总结。

核心理念是正确的。SQLite作为存储引擎，通过外部添加复制功能，已被至少八个不同需求和不同协议的团队重新发明。没有人发现停止这样做的理由。

设计空间存在三个角落，它们按顺序出现。首先是共识机制（rqlite、dqlite）：一个领导者、强一致性、集群。其次是流式传输（Litestream）：一个写入者、低成本恢复、无集群。最后是合并机制（cr-sqlite和本地优先运动的部分内容）：多个写入者、最终一致性。每种方案都针对不同问题，大多数争论本质上是用户之间关于"究竟在解决什么问题"的讨论。

资金流向了平台化。rqlite、dqlite和Litestream都是开源且免费的。而那些成功融资或被收购的项目，正是将复制SQLite转化为可计费服务的团队。这是基础设施类创意的通常结局，我对此并不介意。但值得注意的是，在有人开始出售这个想法之前，这个想法作为开源项目已经存在了八年。

rqlite 依然存在。它如今比 2014 年做得更好，仍然是一款你想要运行、完全理解且无需付费的容错关系数据库时的首选方案。十二年过去，我对它在行业中的定位感到满意。

标签

#

数据库

分布式系统

Go

开源

rqlite

sqlite