被高估的分布式与单机系统的尊严：记一次向 SQLite 的迁徙

十月中旬的一个周五深夜，我收到了一封来自个人云主机监控的告警邮件：一台 4 核 8GB 内存的服务器上，内存占用率突破了 92%，触发了内核的 OOM Killer。那台机器上并没有运行什么庞大的商业服务，仅仅跑着我与几位朋友日常使用的书签全文归档服务、RSS 聚合器以及一个轻量级的个人财务记账工具。

登录终端用 htop 查看时，眼前的景象颇具讽刺意味：真正处理业务逻辑的三个 Go 服务加起来只占用了不到 65MB 内存；而为了支撑它们运转的“基础设施”——一个容器化的 PostgreSQL 实例、一个 Redis 缓存容器、一个消息队列代理以及容器守护进程本身——却联手吞噬了将近 6.5GB 的物理内存。

这让我想起软件工程领域一种普遍却鲜少被反思的“简历驱动型架构（Resume-Driven Development）”惯性：即便我们面对的只是一个每天几万次请求、数据量在十年内都未必能超过 20GB 的系统，我们也习惯于先把大厂应对亿级流量的分布式蓝图按比例缩小，强行塞进一台原本可以极其轻快的小服务器里。

一、网络边界上的隐形税

在传统的客户端-服务端数据库架构中，每一次看似简单的查询背后都隐藏着一连串跨越进程与网络边界的固定成本。哪怕应用与数据库部署在同一台物理宿主机上，一次标准的 SQL 查询依然需要经历连接池借用、协议封包、Loopback 套接字上下文切换、数据库进程解析执行、结果集序列化以及用户态内存拷贝。

而在 SQLite 这样的进程内（In-Process）数据库中，数据库引擎本身就是链接在应用程序内部的一段函数调用。查询数据不再是一次网络通信，而是直接通过指针读取操作系统页缓存（Page Cache）或内存映射文件（mmap）。

“在分布式系统中，我们为了解决网络不可靠而引入了重试、幂等、分布式锁与最终一致性；但很多时候，最优雅的解法是先问一句：这台机器真的装不下你的数据吗？” — 摘自迁移过程中的架构手记

现代 NVMe SSD 的随机 4K 读取 IOPS 已经轻松突破数十万，单机多核 CPU 的处理能力更是远超十年前的机房刀片服务器。当延迟从毫秒级（0.8ms ~ 2.5ms）骤降到微秒级（15μs ~ 40μs）时，过去为了避免 N+1 查询而精心设计的复杂多层 Redis 缓存策略，突然失去了存在的必要——因为直接从本地 B-Tree 索引中读取一行记录，本身就比通过 TCP 协议去向本地 Redis 请求一次键值还要快。

二、打破陈旧印象：WAL 模式与并发调优

许多开发者对 SQLite 的印象仍停留在“一旦写入就会锁死整张表”的早期阶段。事实上，自开启预写式日志（Write-Ahead Logging, WAL）模式并配合合理的编译与运行时连接池配置后，SQLite 能够非常从容地实现多读单写并发（Multiple Readers, Single Writer）：读操作完全不会阻塞写操作，写操作也不会阻塞读操作。

在这次重构中，我把读写分离成了两个标准库连接池：一个允许最大 16 个并发连接的只读池（ReadPool），以及一个严格限制最大连接数为 1 的写入池（WritePool）。每次应用启动时，通过以下初始化指令完成调优：

-- 开启 WAL 日志模式，读写互不阻塞
PRAGMA journal_mode = WAL;

-- 在 WAL 模式下，NORMAL 同步级别兼具断电安全性与高吞吐
PRAGMA synchronous = NORMAL;

-- 设置 5 秒忙等待超时，配合应用层单写连接池彻底消除 SQLITE_BUSY
PRAGMA busy_timeout = 5000;

-- 分配约 64MB 内存页缓存与 256MB 内存映射 I/O
PRAGMA cache_size = -64000;
PRAGMA mmap_size = 268435456;

-- 临时表与索引存放于内存，启用外键约束检查
PRAGMA temp_store = MEMORY;
PRAGMA foreign_keys = ON;

将写连接池大小限制为 SetMaxOpenConns(1) 是一个反直觉却极为有效的技巧：与其让多个并发写事务在 SQLite 内部锁机制上互相争抢并抛出 SQLITE_BUSY，不如直接在 Go 语言极度轻量的通道（Channel）层面让写操作自然排队。实测表明，在一台普通的双核云主机上，单个写连接配合事务批处理，每秒可以轻松完成超过 8,000 次独立写入。

三、迁移前后的真实基准对比

花了一个周末将四个离散服务收敛为单一二进制文件，并把 140 万条历史归档记录与 FTS5 全文分词索引导入单个 archive.db 文件后，我在同一台服务器上使用真实生产流量回放进行了对比测试：

观测指标	迁移前 (Go + Docker PG + Redis)	迁移后 (Go 单体 + SQLite WAL)	变化幅度
常驻物理内存 (RSS)	1,840 MB	48 MB	-97.4%
首页聚合查询延迟 (P95)	14.2 ms	0.38 ms	快 37 倍
全文检索响应时间 (P99)	46.5 ms	3.1 ms (FTS5 Trigram)	快 15 倍
冷启动至可服务耗时	19.0 秒	0.08 秒	近乎瞬时
部署与迁移产物	4 个镜像 + 3 份编排配置	1 个二进制 + 1 个 .db 文件	零外部依赖

四、灾难恢复与系统的寿命

单机系统唯一需要严肃回答的问题是：如果服务器硬盘损坏怎么办？对此，我引入了 Litestream 作为旁路守护进程。它会实时监听 SQLite 的 WAL 日志帧变化，并以秒级的延迟将增量页压缩流式上传至异地对象存储（S3 兼容存储）。

这带来了一种令人极度安心的运维体验：整个系统的全部状态就浓缩在一个普通的磁盘文件里。当我需要在本地笔记本上复现线上问题时，不再需要导出 SQL 转储、启动 Docker 容器、恢复快照；我只需要一条 scp 命令把数据库文件拉到本地，直接运行程序即可。

二十年后再回头看，很多复杂的分布式中间件或许早已停止维护、文档湮灭；但那个遵循 SQLite 文件格式规范的 .db 文件，大概率依然能被那时的任何一台计算机直接打开。对于一个希望陪伴自己十年、二十年的个人软件而言，这种可预期、可迁移、不求人的独立性，才是单机系统最大的尊严。