rqlite十二年演进：分布式SQLite的共识与云原生之路

软件 2026-10-24 01:16 5 阅读来源： Hacker News 精选

rqlite发布十二周年，确立分布式SQLite共识标准。从2014年结合Raft算法起步，历经dqlite、Litestream等演进，CP架构与云原生适配成核心脉络。

从 rqlite 到分布式 SQLite：十二年演进史

2014 年 9 月，rqlite 作为首个结合 Raft 共识算法与 SQLite 的开源系统发布。其核心逻辑是将写入操作在集群中复制，确保单节点故障不会导致数据丢失。该项目于同一周末上线 GitHub。在随后的几年里，尽管“分布式 SQLite”逐渐成为一个包含十余个项目、部分获得风险投资支持的独立类别，但 rqlite 始终是该领域的先行者。

2014 年：rqlite 的诞生与设计基石

rqlite 的开发源于具体需求：当时 jut.io 的一个集群系统需要少量关系型存储，但在决定由哪个节点承担存储任务时缺乏明确方案。通过共识协议复制 SQLite 解决了这一问题。虽然团队最终在工作中采用了其他路径，但鉴于该问题的普遍性及解决方案的精简性，开发者继续构建并维护了 rqlite。

初版 rqlite 基于 goraft 库开发，同时参考了 InfluxDB 和 etcd 的实现（开发者后来也成为 InfluxDB 的核心贡献者）。2016 年初，项目切换至 HashiCorp 的 Raft 实现，并沿用至今。

在设计初期确立的一项原则从未改变：rqlite 是一个 CP（一致性/分区容错性）系统。多数派必须达成一致，少数派在分裂时拒绝写入，所有写操作必须通过领导者进行。HTTP API、读取一致性级别及快照功能均建立在此基础之上。

早期探索：Expensify 与 ActorDB

在 rqlite 出现前后，已有其他团队探索类似概念。Expensify 多年来在其基础设施中使用 Paxos 类协议复制 SQLite，并于 2016 年发布了 Bedrock。此外，Erlang 系统 ActorDB 为每个“actor”提供由 Raft 复制的 SQLite 数据库，其出现时间与 rqlite 大致同期。这些案例表明，“将 SQLite 纳入分布式环境”的想法在当时已具备可行性。

2017 年：dqlite 与嵌入式场景

佳能公司开发了 dqlite，旨在让 LXD 和 MicroK8s 在不依赖 etcd 的情况下嵌入复制存储。马克·沙特尔沃斯曾就此与 rqlite 开发者进行过交流。dqlite 最初使用 Go 语言编写，后改用 C 语言重写其 Raft 库。

dqlite 与 rqlite 的主要区别在于封装形式：dqlite 是嵌入式库，而 rqlite 是独立运行的服务器。这反映了不同的使用场景——前者适用于产品内部集成，后者适用于作为外部服务部署。

2021-2022 年：Litestream、LiteFS 与理念转变

2021 年初，Ben Johnson（前 InfluxDB 同事）发布了 Litestream。该项目完全摒弃共识机制，转而监控 SQLite 的 WAL（预写式日志）并将其传输至 S3。其核心论点在于：大多数应用无需集群，仅需单机器运行；若机器失效，重点在于快速恢复而非实时同步。这一观点推动了随后几年“SQLite is enough”理念的流行。

Litestream 与 rqlite 针对的问题不同：前者关注机器宕机后的恢复成本，后者关注高可用性下的实时故障转移。Fly.io 于 2022 年聘请 Ben Johnson 并推出 LiteFS，在文件系统层面复制 SQLite 并利用 Consul 租约机制。这是首次尝试将复制的 SQLite 转化为平台内置功能，而非用户自行部署的服务。值得注意的是，Litestream 的设计思路也反向影响了 rqlite v8.0 对 SQLite WAL 的处理方式。

2022 年：CRDT 扩展与 libSQL 分支

同年出现了两个采用不同技术路径的项目。cr-sqlite 通过扩展 SQLite 引入 CRDT（无冲突复制数据类型），允许多个写入者在无领导者的情况下分离与合并数据。这填补了设计空间中的 AP（可用性/分区容错性）角落，适用于本地优先应用中 CP 保证成为障碍的场景。

libSQL 则是 SQLite 本身的分支。由于 SQLite 官方项目不接受外部贡献且保持封闭，libSQL 在此基础上构建了托管服务，并在边缘节点提供复制能力。2026 年，Supabase 收购了 libSQL。与此同时，SQLite Cloud 出现，提供基于 Raft 复制的托管 SQLite 服务，其架构最接近 rqlite 的原始设计，但以云服务形式呈现。

2022 年以后：云原生与平台化

随着云服务商入场，SQLite 的角色进一步演变。某云平台于 2022 年宣布 D1，将 SQLite 作为其边缘网络中的无服务器数据库，并将数据存储置于耐用对象中。Turso 等服务也呈现相同形态。这一类别从“用户自行运维的软件”转变为“用户购买的付费服务”。

总结：十二年的行业观察

回顾过去十二年，分布式 SQLite 领域呈现出三个主要特征：

核心验证：以 SQLite 为存储引擎、外层增加复制的方案已被至少八个团队在不同需求和协议下重新发明，证明该方向具有持续价值。
设计空间的三角：
- 共识型（CP）：如 rqlite、dqlite。特征为单一领导者、强一致性、集群模式。
- 流媒体型：如 Litestream。特征为单一写入者、低成本恢复、无集群依赖。
- 合并型（AP）：如 cr-sqlite 及本地优先运动相关项目。特征为多写入者、最终一致性。
每种方案针对特定问题提供正确解法，争议往往源于用户需求的差异。
资本流向：资金主要集中在将复制的 SQLite 转化为付费服务的平台项目中。相比之下，开源工具本身多为免费。这一现象符合基础设施创新的常见规律，但需铭记：该想法在商业化之前已在开源社区存在八年。