rqlite 深度解析：当 SQLite 遇见分布式共识

引子：一个看似不可能的命题

SQLite 是世界上最流行的数据库。它运行在每一部智能手机、每一台电脑、无数个嵌入式设备里。它小巧、快速、可靠，有一个致命弱点：它是单机的。

如果你需要高可用性，传统答案是：放弃 SQLite，去用 PostgreSQL、MySQL、或者更重的分布式数据库如 CockroachDB。

但 Philip O'Toole 在 2014 年提出了一个疯狂的问题：如果保留 SQLite 的一切优点，只给它加上分布式共识能力，会怎样？

10 年后，rqlite 已经是一个成熟的生产级项目：

• 14,000+ GitHub stars
• 完整的 Raft 共识实现
• 支持 66 种语言的客户端
• 被用于从边缘设备到云原生系统的各种场景

最妙的是：它还是一个二进制文件，零依赖，秒级部署。

第一部分：问题的本质——为什么分布式这么难？

在理解 rqlite 的解决方案之前，我们需要理解问题的本质。

CAP 定理的阴影

分布式系统的铁律：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），三者最多取其二。

大多数现代系统选择了可用性 + 分区容错性（AP），牺牲强一致性。这意味着你的数据可能暂时不一致，但最终会收敛。

但对于关键数据——配置信息、账户余额、库存数量——你需要强一致性。你不能接受"最终一致"，你需要知道写入成功后，所有节点都看到了同样的数据。

共识算法：让分布式系统达成一致

实现强一致性的标准答案是共识算法。最著名的两个：

Paxos（1990s）：理论上优雅，实践中难以理解和实现。Google 的 Chubby、ZooKeeper 都基于此。

Raft（2014）：Stanford 的 Diego Ongaro 和 John Ousterhout 设计的 Paxos 替代品。核心设计目标是可理解性。

Raft 的工作原理可以概括为：

1. 领导者选举：集群选出一个 Leader 处理所有写入
2. 日志复制：Leader 把写入操作追加到日志，复制到多数节点后才确认提交
3. 安全性：只有包含已提交日志条目的节点才能当选 Leader

关键保证：只要多数节点存活，系统就能继续工作。

第二部分：rqlite 的核心直觉——不要做太多

rqlite 的设计哲学非常克制：只做一件事，把它做好。

架构分层

rqlite 由三个清晰分离的子系统组成：

┌─────────────────────────────────────────────┐
│           HTTP API Layer                    │  ← 对外接口
├─────────────────────────────────────────────┤
│           Raft Consensus Layer              │  ← 分布式共识
├─────────────────────────────────────────────┤
│           SQLite Database                   │  ← 存储引擎
└─────────────────────────────────────────────┘

HTTP 层：处理 REST API 请求，返回 JSON 结果。支持批量操作、事务、参数化查询。

Raft 层：基于 HashiCorp 的 Raft 实现。处理领导者选举、日志复制、快照、成员变更。

SQLite 层：嵌入式的 SQLite 数据库。每个节点都有一个完整的副本。

写入路径：强一致性的保证

当客户端发送写入请求时：

1. 如果请求发送到 Leader：

   • Leader 将操作追加到 Raft 日志
   • 异步复制到所有 Follower
   • 等待多数节点确认（quorum）
   • 提交到本地 SQLite
   • 返回成功给客户端

2. 如果请求发送到 Follower：

   • Follower 返回 301 重定向到 Leader
   • 或（可选）自动转发到 Leader

关键洞察：所有写入都通过 Raft 日志序列化。这意味着即使多个客户端并发写入，最终顺序也是确定的。

读取路径：灵活的一致性级别

rqlite 提供三种读取一致性选项：

这种灵活性让开发者可以在一致性和性能之间权衡。

第三部分：技术细节——优雅的工程实践

为什么选择 SQLite？

rqlite 不是第一个尝试分布式的 SQLite 项目。但它的选择非常精准：

SQLite 的优势：

• 零配置、零管理
• 单文件存储
• 事务支持（ACID）
• 全文搜索、JSON、GIS 扩展
• 经过数十亿设备的实战检验

rqlite 增加的：

• Raft 共识层
• HTTP API 包装
• 自动集群管理

集群管理：比 etcd 还简单

rqlite 的集群形成非常简单：

# 第一个节点（等待其他节点加入）
rqlited -node-id node1 -http-addr 0.0.0.0:4001 -raft-addr 0.0.0.0:4002 \
  -bootstrap-expect 3 /var/lib/rqlite

# 第二个节点（加入集群）
rqlited -node-id node2 -http-addr 0.0.0.0:4001 -raft-addr 0.0.0.0:4002 \
  -join http://node1:4001 /var/lib/rqlite

# 第三个节点（加入集群）
rqlited -node-id node3 -http-addr 0.0.0.0:4001 -raft-addr 0.0.0.0:4002 \
  -join http://node1:4001 /var/lib/rqlite

集群自动完成领导者选举、日志同步、故障检测。

自动发现：Kubernetes 原生支持

rqlite 支持多种服务发现机制：

• Kubernetes：通过 DNS 或 Headless Service 自动发现
• Consul：服务注册与发现
• etcd：复用现有的键值存储
• DNS：基于 DNS SRV 记录
• 静态配置：直接指定节点地址

备份与恢复：云原生设计

# 热备份到 S3
rqlite -auto-backup s3://bucket/path

# 从 S3 恢复
rqlite -auto-restore s3://bucket/path

支持 AWS S3、MinIO、Google Cloud Storage。备份在后台进行，不影响服务。

第四部分：与同类项目的对比

rqlite vs etcd

两者都使用 Raft，都定位为"分布式配置存储"。关键区别：

• etcd：纯键值，无 SQL，适合服务发现
• rqlite：关系型 + SQL，适合结构化配置数据

Tailscale 在 2022 年从 etcd 迁移到 SQLite（配合 Litestream），原因正是 etcd 的复杂性：

"etcd 的索引代码是 bespoke code。每次别人要碰它，我都得解释。我们需要更容易上手的东西。"

rqlite vs CockroachDB

两者都提供分布式 SQL，但设计目标完全不同：

• rqlite：简单第一，适合 GB 级数据，运维成本极低
• CockroachDB：企业级，TB+ 级数据，完整的分布式事务

如果你需要水平写入扩展或跨地域部署，选 CockroachDB。如果你想要一个"高可用的 SQLite"，选 rqlite。

rqlite vs dqlite

dqlite（distributed SQLite）是 Canonical 的项目，用于 Ubuntu 的分布式系统。两者非常相似，主要区别：

• rqlite：Go 编写，HTTP API，更广泛的语言支持
• dqlite：C 编写，C/Raft 实现，与 LXD 深度集成

第五部分：使用场景——rqlite 适合什么？

场景 1：分布式配置管理

把 rqlite 当作"带 SQL 的 etcd"：

-- 存储服务配置
CREATE TABLE services (
    name TEXT PRIMARY KEY,
    endpoint TEXT,
    health_check_interval INTEGER,
    max_retries INTEGER
);

-- 存储 feature flags
CREATE TABLE feature_flags (
    flag_name TEXT PRIMARY KEY,
    enabled BOOLEAN,
    rollout_percentage INTEGER
);

高可用、强一致、支持复杂查询。

场景 2：边缘计算与 IoT

rqlite 的轻量级使其成为边缘设备的理想选择：

• 单二进制文件，<100MB 内存占用
• 自动故障转移
• 断网时本地 SQLite 仍可工作
• 恢复后自动同步

场景 3：云原生应用的轻量级状态存储

不需要 Kafka + PostgreSQL + Redis 的复杂栈：

• 用户会话：关系型存储，支持过期
• 任务队列：利用 SQLite 的 ACID 保证
• 指标数据：配合全文搜索和 JSON 扩展

场景 4：开发与测试环境

生产用 PostgreSQL，开发测试用 rqlite：

• 完全兼容 SQL
• 秒级启动
• 无需 Docker Compose 编排

第六部分：rqlite 9.0 的新特性——Change Data Capture

2024 年发布的 rqlite 9.0 引入了 CDC（变更数据捕获），这是一个重大进化。

什么是 CDC？

CDC 自动捕获数据库变更事件（INSERT、UPDATE、DELETE），推送到外部系统。

// CDC 事件示例
{
  "table": "users",
  "operation": "INSERT",
  "row_id": 42,
  "new_values": {
    "id": 42,
    "name": "Alice",
    "email": "alice@example.com"
  }
}

为什么这很重要？

CDC 让 rqlite 从"被动存储"变成"事件源"：

• 实时同步到 Elasticsearch 做搜索
• 触发 webhook 通知其他服务
• 构建事件溯源（Event Sourcing）架构
• 数据管道：rqlite → Kafka → 数据仓库

实现挑战

CDC 在 SQLite 上并不容易实现，因为 SQLite 没有内置的变更流机制。rqlite 的解决方案：

• 在 Raft 日志层面拦截变更
• 异步推送到配置的 HTTP 端点
• 支持批处理和重试

第七部分：10 年演进——从原型到生产

rqlite 从 2014 年到 2024 年的演进展示了优秀开源项目的成长轨迹：

2014：起步

• Philip O'Toole 开始项目
• 基本 Raft + SQLite 集成

2016：共识层升级

• 从自定义 Raft 实现迁移到 HashiCorp Raft
• 大幅提升稳定性和性能

2017：发现服务

• AWS Lambda 驱动的节点发现
• 自动集群形成

2020：Protocol Buffers

• 内部数据结构从 JSON 迁移到 Protobuf
• 更高效的节点间通信

2021：重大架构重构

• 6.0 版本重构节点间通信
• 移除脆弱的 HTTP URL 映射机制
• 引入多路复用的逻辑连接

2022：Jepsen 测试

• 引入 Jepsen-style 一致性测试
• 验证线性一致性保证

2023：大数据集支持

• 优化 GB 级数据集的处理
• 更快的重启速度

2024：CDC 与 10 周年

• 9.0 引入 Change Data Capture
• Philip 撰写"10 年分布式系统开发观察"

尾声：简单性的胜利

rqlite 的成功不是因为它做了最多的事情，而是因为它拒绝做太多事情。

它没有去重新发明存储引擎（用 SQLite），没有去重新发明共识算法（用 Raft），没有去重新发明查询语言（用 SQL）。

它只是把这些经过验证的技术，用正确的方式组合在一起，然后提供了一个极其简单的接口。

在这个追求"云原生"、"微服务"、"中台"的时代，rqlite 提醒我们：简单性本身就是一种特性。

正如 Philip O'Toole 在 10 周年博客中写的：

"分布式系统很难。但如果你想理解它们是如何工作的，rqlite 是一个很好的例子。它的设计和实现经过了深思熟虑，各个组件之间有清晰的分离。"

参考链接

• rqlite 官网: https://rqlite.io/
• GitHub: https://github.com/rqlite/rqlite
• 快速开始: https://rqlite.io/docs/quick-start/
• 设计文档: https://rqlite.io/docs/design/
• Raft 论文: https://raft.github.io/raft.pdf
• Philip O'Toole 的博客: https://philipotoole.com/
• 10 周年回顾: https://philipotoole.com/rqlite-turns-10-observations-from-a-decade-building-distributed-systems/

后记：一个二进制文件的哲学

我特别喜欢 rqlite 的部署体验：

curl -L https://github.com/rqlite/rqlite/releases/latest/download/rqlited-linux-amd64 \
  -o rqlited
chmod +x rqlited
./rqlited ~/node.1

一个文件，一个命令，一个高可用的分布式数据库。

这让我想起 Unix 哲学：做一件事，把它做好；组合小工具解决大问题。

rqlite 没有试图成为下一个 CockroachDB 或 Spanner。它只想成为"高可用的 SQLite"。而这，恰恰是它最迷人的地方。

写于 2026 年 4 月 5 日，参考 rqlite 官方文档、Philip O'Toole 的技术博客及 Raft 共识算法论文。