Cloudflare 公布了 D1 无服务器 SQL 数据库控制面的重新设计，目标是支撑数百万个数据库。这套架构要解决的核心问题很具体：别让集中式管理操作变成瓶颈。
D1 控制面由三块拼起来：Postgres 负责事务性元数据，ClickHouse 负责分析，Workers KV 存放全局复制的路由数据。查询处理留在边缘，与集中式管理操作分开，再配合分布式元数据缓存、连接池、异步工作流和周期性健康检查来提升扩展性、从故障中恢复。
D1 在 2022 年发布，是构建在 SQLite 之上的无服务器 SQL 数据库，设计目标是贴近应用运行在 Cloudflare 的全球网络上。过去一年，日活数据库数量增长了 18 倍。
心跳机制怎么自愈
Cloudflare 用 30 秒一次的心跳，加上按数据库施加的抖动，让每个 D1 Durable Object 与 Postgres 对账。Postgres 是数据库是否存在、账户限额是多少的唯一事实来源。
这套机制让失败的创建或删除操作能自我修正：孤立对象被标记为已删除，Workers KV 的路由元数据如果尽力更新失败，也会被修复。Cloudflare 全栈软件工程师 David Laban 和首席工程师 Lambros Petrou 写道，心跳可以容忍略微过时的数据，因此可以由 Hyperdrive 的多层缓存或 Postgres 只读副本提供。这条心跳流让 Durable Object 能就数据库的创建与删除，自我修正到与事实来源 Postgres 一致。
查询路径绕开 Postgres
为了让 D1 查询不落到集中式 Postgres 上，请求从 Edge API Worker 经 Eyeball Worker 直接路由到对应的 D1 Durable Object。Edge API Worker 负责认证、授权、限流和请求校验；Eyeball Worker 则信任编码在 D1 Bindings 里的数据库级授权，避免在查询路径上重复检查。
两位工程师还解释了既然有 Hyperdrive 缓存，为什么还要用 Workers KV：KV 是持久数据存储，不只是缓存。如果某个条目从 KV 的边缘缓存中掉出，读取会由 KV 自己的存储提供，而不是回到 Postgres，从而把 Postgres 挡在数据面之外。假如出现灾难性的缓存清空，一百万个数据库同时来取路由信息，会导致亚稳态故障。
限额靠异步更新
D1 的存储限额通过异步用量更新来执行，这些更新排队并批量处理，保护 Postgres 免受写入尖峰冲击。账户总量通过增量存储差值预先聚合，避免对拥有数百万数据库的账户做昂贵扫描和写入争用。Durable Objects 通过 Hyperdrive 的短时缓存检查这些总量，并阻止会超出账户限额的写入。
在 Reddit 讨论中，用户 isaackogan 评论说，这确实是一套令人印象深刻的架构，但大部分收益来自它是一个运行在离你很近的边缘存储上的进程内数据库，其余都是围绕它的编排。Cloudflare 可以利用其庞大的全球数据中心存在，做到小团队传统上不可能做到的事，也就是规模经济在起作用。在另一个热门讨论中，多名 Reddit 用户认为 D1 不可靠，对其在生产负载下的可用性和稳定性提出担忧。
热门跟贴