强曰为道
与天地相似,故不违。知周乎万物,而道济天下,故不过。旁行而不流,乐天知命,故不忧.
文档目录

rqlite 完全指南 / 第 1 章:rqlite 概念与适用场景

第 1 章:rqlite 概念与适用场景

了解 rqlite 的核心理念、技术原理以及它最适合解决的问题。


1.1 什么是 rqlite?

rqlite 是一个轻量级的分布式关系数据库,它将 SQLite 作为底层存储引擎,通过 Raft 共识协议(Consensus Protocol)实现多节点之间的数据复制。你可以把它理解为:

SQLite(嵌入式数据库) + Raft(分布式共识) = rqlite(分布式 SQLite)

rqlite 由 Philip O’Toole 于 2014 年发起,使用 Go 语言编写。它的核心设计目标是:

  • 简单性:部署只需一个二进制文件,无外部依赖
  • 高可用性:通过 Raft 协议实现多节点复制,任何少数节点宕机不影响服务
  • 强一致性:写入操作通过 Leader 节点保证线性一致性(Linearizability)
  • HTTP 友好:所有操作通过 RESTful HTTP API 进行,无需专用客户端库

与其他数据库的对比

特性rqliteSQLitePostgreSQLetcdTiKV
部署复杂度⭐ 极低⭐ 极低⭐⭐⭐ 高⭐⭐ 中⭐⭐⭐ 高
分布式复制✅ Raft✅ 流复制✅ Raft✅ Raft
SQL 支持✅ 完整✅ 完整✅ 完整❌ KV❌ KV
存储模型关系型关系型关系型KVKV
内存占用极低
适用数据规模小到中小到中
ACID 事务部分
HTTP API✅ 原生

1.2 Raft 共识协议简述

Raft 是一种分布式共识算法,由 Diego Ongaro 和 John Ousterhout 于 2014 年提出,旨在比 Paxos 更易理解。rqlite 使用 Hashicorp 的 Raft 实现(hashicorp/raft)。

Raft 的三个核心角色

┌─────────────────────────────────────────────┐
│                  Raft 集群                    │
│                                              │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│   │  Leader  │  │ Follower │  │ Follower │  │
│   │  (写入)   │  │  (复制)   │  │  (复制)   │  │
│   └────┬─────┘  └────┬─────┘  └────┬─────┘  │
│        │             │             │         │
│        └─────────────┼─────────────┘         │
│           复制日志 (Log Replication)           │
│                                              │
│   ┌──────────┐                               │
│   │ Candidate│  ← 当 Leader 宕机时触发选举     │
│   │  (候选)   │                               │
│   └──────────┘                               │
└─────────────────────────────────────────────┘
角色职责数量
Leader处理所有写请求,将日志复制到 Follower1 个
Follower接收 Leader 的日志复制,响应读请求(取决于一致性级别)1 至多个
Candidate当 Follower 超时未收到心跳时,发起选举临时状态

Raft 日志复制过程

  1. 客户端发送写请求到 Leader
  2. Leader 将操作追加到本地日志(Log Entry)
  3. Leader 将日志条目复制到所有 Follower
  4. 当多数(Quorum)节点确认后,Leader 提交(Commit)该条目
  5. Leader 应用到状态机(SQLite),并将结果返回客户端
  6. Follower 在下一轮中提交并应用该条目

关键概念: rqlite 中"多数"意味着一个 3 节点集群可以容忍 1 个节点故障,5 节点集群可以容忍 2 个节点故障。


1.3 rqlite 的架构总览

客户端 (curl / SDK)
        │
        ▼
┌─────────────────────────────────────────┐
│              HTTP API 层                 │
│         (Go net/http server)             │
├─────────────────────────────────────────┤
│            rqlite 核心逻辑                │
│  ┌────────────┐   ┌──────────────────┐  │
│  │  查询引擎    │   │   执行引擎        │  │
│  │  (Query)    │   │   (Execute)      │  │
│  └─────┬──────┘   └────────┬─────────┘  │
│        │                   │             │
│        ▼                   ▼             │
│  ┌──────────────────────────────────┐   │
│  │      Raft 共识层                  │   │
│  │   (hashicorp/raft)               │   │
│  └────────────────┬─────────────────┘   │
│                   │                      │
│                   ▼                      │
│  ┌──────────────────────────────────┐   │
│  │      SQLite 存储引擎              │   │
│  │   (mattn/go-sqlite3)             │   │
│  └──────────────────────────────────┘   │
└─────────────────────────────────────────┘
        │
        ▼
   磁盘文件 (SQLite DB + Raft Log)

关键组件说明

组件作用技术实现
HTTP API 层接收客户端请求,返回 JSON 响应Go net/http
查询引擎处理 SELECT 查询(可从 Follower 读取)自定义解析
执行引擎处理 INSERT/UPDATE/DELETE(必须经 Leader)Raft 日志复制
Raft 共识层管理节点间日志复制和 Leader 选举hashicorp/raft
SQLite 存储引擎实际存储数据mattn/go-sqlite3(CGO)

1.4 核心特性详解

1.4.1 一致性级别(Consistency Level)

rqlite 提供灵活的一致性级别配置:

级别说明适用场景
none任意节点读取,可能读到过期数据可容忍短暂不一致的高并发读
weak从 Leader 读取,但不确认 Leader 身份一般业务读取
strong从 Leader 读取,且确认 Leader 身份需要强一致性的读取

1.4.2 数据库发现(Discovery)

rqlite 支持自动集群发现:

  • 内置发现服务https://discovery.rqlite.io
  • 自定义发现:支持 Consul、etcd 等外部发现机制
  • 静态配置:直接指定节点地址

1.4.3 SQLite 兼容性

rqlite 支持绝大部分 SQLite 的 SQL 语法,包括:

  • 创建表、索引、视图
  • CRUD 操作
  • 事务(BEGIN / COMMIT / ROLLBACK)
  • PRAGMA 配置
  • FTS5 全文搜索
  • JSON 函数(SQLite 3.38+)

限制: rqlite 不支持 ATTACH DATABASE,因为每个节点使用独立的 SQLite 文件。


1.5 适用场景

✅ 推荐使用的场景

场景说明
IoT 数据存储边缘设备数量有限,数据量中等,需要高可用
配置管理服务配置的分布式存储和同步
小型 SaaS 后端用户量在数万到数十万级别的应用
嵌入式系统需要 SQL 能力但不想引入重量级数据库
微服务状态存储服务发现元数据、分布式锁等
开发和测试环境快速搭建有完整 SQL 能力的数据库
边缘计算节点资源有限,需要轻量高可用方案

❌ 不推荐使用的场景

场景原因推荐方案
海量数据(TB 级别)SQLite 单文件存储,不适合大数据PostgreSQL、TiDB
超高并发写入(万级 TPS)Raft 日志复制有瓶颈Redis Cluster、TiKV
复杂分析查询不支持分布式查询计划ClickHouse、DuckDB
跨数据中心部署Raft 延迟敏感CockroachDB、YugabyteDB

1.6 业务场景案例

场景一:智能家居配置中心

一个智能家居平台有 50+ 设备类型,需要存储设备配置和规则引擎:

┌──────────┐     ┌──────────┐     ┌──────────┐
│  Web UI  │     │  App     │     │  规则引擎  │
└────┬─────┘     └────┬─────┘     └────┬─────┘
     │                │                │
     └────────────────┼────────────────┘
                      │
              ┌───────▼───────┐
              │   rqlite 集群   │
              │  (3 节点)      │
              └───────────────┘

为什么选 rqlite

  • 配置数据量小(GB 级别)
  • 读多写少(8:2 比例)
  • 需要高可用,但不想维护 MySQL 集群
  • HTTP API 直接对接 Web 端,无需额外驱动

场景二:CI/CD 平台的构建状态存储

一个自研 CI/CD 平台需要记录构建任务状态:

CREATE TABLE builds (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    project TEXT NOT NULL,
    branch TEXT NOT NULL,
    commit_hash TEXT NOT NULL,
    status TEXT CHECK(status IN ('pending', 'running', 'success', 'failed')),
    started_at DATETIME,
    finished_at DATETIME,
    log_url TEXT
);

CREATE INDEX idx_builds_project ON builds(project, branch, status);

为什么选 rqlite

  • 构建记录数据量可控
  • 需要 SQL 查询能力(按项目、分支、状态过滤)
  • 集群 3 节点提供高可用即可
  • Go 语言写的 CI 工具可以直接用 HTTP API

1.7 rqlite 的版本历史

版本系列重要特性
v1-v4基础 Raft 复制,单文件分发
v5引入自动 Snapshot,改进集群稳定性
v6基于 Raft 日志的备份恢复,性能大幅提升
v7改进 Join 机制,更好的集群成员管理
v8最新稳定版,改进性能和可观测性,支持更多 SQLite 扩展

1.8 扩展阅读


本章小结

要点内容
rqlite 是什么基于 Raft 的分布式 SQLite
核心优势简单部署、高可用、HTTP 友好
共识协议Raft,通过日志复制保证一致性
最佳场景小到中规模、读多写少、需要 SQL
不适合海量数据、超高并发、复杂分析

下一章:第 2 章:安装与集群搭建