• 缓存
• 后端
• 数据库

导读

本篇文章以开源项目 readyset-server 的官方 README 为骨架，结合仓库源码，系统讲解 ReadySet 作为 Postgres / MySQL 透明数据库缓存的工作原理、快速部署方式、server 与 adapter 双进程架构、核心命令行参数与运行模式。读完本文，你将掌握 ReadySet 的核心概念（wire-compatible、replication stream 驱动的自动失效、数据流图增量维护）、本地开发环境的搭建步骤，以及在生产场景中如何组合readyset-server与readyset适配器进程完成缓存部署。

ReadySet 是什么：一张挂在数据库前面的透明缓存层

根据 readyset-server/README.md 的定义，ReadySet 是一个面向 Postgres 与 MySQL 的透明数据库缓存（transparent database cache）：

• 它位于应用与数据库之间，把复杂的 SQL 读请求转化为内存键值存储级别的快速查找；
• 与应用要求一致，无需重写应用代码、无需手动处理缓存失效（cache invalidation）；
• 与其他缓存方案不同，它通过**消费数据库的复制流（replication stream）**自动把缓存查询结果与上游数据库保持同步；
• 它在线上协议上与 Postgres 和 MySQL 兼容（wire-compatible），可直接对接你现有的 ORM 或数据库客户端。

从源码结构看，这一描述与仓库的分层设计完全对应：readyset-server是数据流数据库服务器（Cargo.toml 中description = "The Readyset>- [id=1, title=Hello world, votes=42] + [id=1, title=Hello world, votes=43]

负记录向后续视图宣告旧行失效、应被删除；连接算子必须对正负记录各执行一次完整连接，才能精确撤销旧的输出行（详见 readyset-server/src/lib.rs）。这一机制正是 README 所宣称"自动与数据库保持同步、无需手动缓存失效"的底层实现。

仓库中的votes集成测试（readyset-server/src/integration.rs）用Article/Vote/VoteCount模型实际验证了这一数据流：先插入文章与投票，再校验聚合出的票数与连接结果的正确性。

线程域（Domain）执行模型

数据流被逻辑划分为线程域（thread domains）（见 readyset-server/src/lib.rs）：

• 每个域内状态访问无需加锁，显著加速需要查询状态的算子（如连接）；
• 跨 worker 的域间通信使用 TCP，同 worker 内使用内存通道；
• 域天然构成机器边界，便于把计算分配到多核与多机。

从 readyset-server/src/startup.rs 可以看到，一个 ReadySet server 实例由三部分构成：对外提供 RPC 的 HTTP 服务（NoriaServerHttpRouter）、包含 Leader 的控制器（Controller）、承载多个 Domain 的 Worker（Worker）；控制面（迁移、结构变更）走 HTTP，数据面（读写与域间数据流）走 TCP 自定义协议（readyset-server/src/startup.rs）。

快速开始：五分钟跑通

README 提供了最简单的一键启动方式：

bash -c "$(curl -sSL https://launch.readyset.io)"

此外也支持通过Docker 镜像或Linux 二进制安装，详细步骤可参考仓库内的 development.md 构建指南。

本地开发环境的运行依赖

若要基于源码本地运行，需要先准备运行期依赖——上游数据库与 Consul（用于 Leader 选举）。仓库 development.md 建议通过 Docker Compose 一次性拉起 Consul、MySQL、Postgres：

cp docker-compose.override.yml.example docker-compose.override.yml docker-compose up -d

仓库自带的 docker-compose.yml 提供了基础的 MySQL（root 密码readyset）与 Postgres 14（wal_level=logical，这是逻辑复制所必需的）容器。完整的部署则需要：一个 MySQL 或 Postgres 上游数据库、一个运行中的 Consul 实例，以及在启动 server 与 adapter 时传入数据库连接串。

注意：Consul 会按部署持久化数据。使用相同的 deployment 名称会沿用之前安装过的缓存查询（development.md）。

从源码构建

ReadySet 完全用 Rust 编写，依赖rust-toolchain.toml指定的工具链版本。构建前需安装 clang、libclang-dev、libssl-dev、liblz4-dev、build-essential 等系统依赖，Ubuntu 下可用：

sudo apt update && sudo apt install -y build-essential libssl-dev pkg-config llvm clang liblz4-dev cmake

macOS 下则需brew install lz4与brew install openssl@1.1（见 development.md）。在性能敏感场景下务必使用--release编译。

双进程架构：Server 与 Adapter

README 反复强调 ReadySet 是"位于应用与数据库之间"的层，实际落地为两个可执行文件：

两个进程通过相同的 deployment 名称互相发现与通信。

启动 Server

cargo run --bin readyset-server --release -- --upstream-db-url <upstream-url> --deployment <deployment name>

使用仓库 docker-compose 环境提供的数据库时：

• MySQL：mysql://root:readyset@127.1/readyset
• PostgreSQL：postgresql://root:readyset@127.1/readyset

使用外部既有数据库时，将<upstream-url>替换为对应连接串即可。

从 readyset-server/src/main.rs 的Options结构可以梳理出 server 的核心参数：

其中AuthorityType定义于 readyset-client/src/consensus/mod.rs：LocalAuthority适合单进程开发调试，StandaloneAuthority则以本地存储目录为权威、支持多 worker。main.rs 中 standalone 模式下authority-address会被解析为deployment_dir（readyset-server/src/main.rs）。

server 主流程（readyset-server/src/main.rs）依次：初始化并行行池与 tracing → 初始化遥测 → 解析外部地址 → 由WorkerOptions构建Builder→ 创建 Authority →builder.start()启动数据流引擎，最后等待 Ctrl-C / SIGTERM 优雅退出。

启动 Adapter

MySQL

cargo run --bin readyset --release -- --database-type mysql --upstream-db-url mysql://root:readyset@127.1/readyset --allow-unauthenticated-connections --address 0.0.0.0:3307 --deployment <deployment name> --prometheus-metrics

Postgres

cargo run --bin readyset --release -- --database-type postgresql --upstream-db-url postgresql://postgres:readyset@127.1/readyset --allow-unauthenticated-connections --address 0.0.0.0:5433 --deployment <deployment name> --prometheus-metrics

adapter 在--address指定的地址监听客户端连接（示例中 MySQL 走 3307、Postgres 走 5433）。从 readyset/src/lib.rs 可以看到：

• --database-type若省略，会从--upstream-db-url/--cdc-db-url推断，两者都提供时会校验一致性（DatabaseType枚举定义在 database-utils/src/lib.rs）；
• --deployment-mode支持standalone（默认，进程内同时跑 adapter 与 server）、embedded_readers、adapter三种模式（readyset/src/lib.rs）；
• --allow-unauthenticated-connections允许免认证连接；否则按--allowed-users或上游 URL 中的账号管理用户。

adapter 启动时还会执行配置自检（verify），校验数据库类型、上游 URL、TLS、复制槽等（readyset/src/verify.rs）。

上游连接配置

server 与 adapter 共享的UpstreamConfig（database-utils/src/lib.rs）提供以下连接参数：

Prometheus 指标暴露

--prometheus-metrics标志会在 adapter 中暴露一个 HTTP 端点，通过 HTTP GET 请求<adapter-address>:6034/metrics即可拉取指标，例如：

curl -X GET 127.0.0.1:6034/metrics

在源码中，server 与 adapter 都会以deployment为标签初始化全局指标记录器（readyset-server/src/main.rs、readyset/src/lib.rs），adapter 还会额外打上upstream_db_type（mysql/psql）标签；指标内容涵盖版本、启动次数、CPU/内存/磁盘/NUMA 节点等主机信息。

Worker 级参数：内存、持久化与特性开关

WorkerOptions（readyset-server/src/builder.rs）是 server 行为调优的核心参数集，其中较常用的包括：

部分实验性 SQL 能力通过特性开关控制（均可用--feature-xxx=false关闭，且必须保证所有 server 与 adapter 进程取值一致，见 readyset-server/src/builder.rs）：

测试与调优建议

仓库 development.md 给出两条实用建议：

• 运行测试：cargo test --skip integration_serial。文件名以_serial结尾的测试不能与其他测试并行（如 readyset-server/src/integration_serial.rs），直接cargo test -p readyset-server可能因包含串行测试而失败；必要时先ulimit -Sn 65535提高文件描述符上限。
• 性能场景务必使用--release编译，并注意 RocksDB 块缓存（--rocksdb-block-cache-mb）的合理设置——源码注释明确指出它是"非平凡缓存查询数据流读性能最大的杠杆"。

许可与社区

ReadySet 采用BSL 1.1许可，4 年后转为开源Apache 2.0；任何节点数量均可免费使用。社区交流与贡献入口详见 readyset-server/README.md 的 Community support 与 Contributing 章节，源码构建指南见 community-development.md。

• 缓存
• 后端
• 数据库