深入底层，脱离热路径：D1 如何扩展至数百万数据库
内容提要
Cloudflare 详解 D1 数据库控制平面架构：为支撑数百万数据库，将查询热路径与控制平面分离，查询经边缘 Worker 直达 SQLite Durable Object，不依赖中心 Postgres；元数据用 Workers KV 缓存，创建、心跳、删除均具自纠正与最终一致性；用量统计经队列批处理，存储限额用增量预聚合，行数限额用 ClickHouse 与 Quicksilver 边缘执行。
延伸解读
控制平面与数据平面分离的架构价值
D1 将查询热路径与控制平面彻底分离：查询请求经边缘 Worker 直达 SQLite Durable Object，不依赖中心 Postgres；而创建、删除、心跳等控制操作才访问中心数据库。这种设计避免了中心瓶颈拖慢每次查询，使系统能支撑数百万数据库。对于构建多租户或 AI 驱动平台的开发者，这一模式值得借鉴：将高频数据操作与低频管理操作解耦，可显著提升可扩展性。
最终一致性与自纠正机制的实际应用
D1 在创建、删除和心跳流程中广泛采用最终一致性与自纠正设计。例如，创建时若 Postgres 写入失败，重试会生成新 ID，旧 Durable Object 通过心跳发现自身无效后自动标记删除；Workers KV 的元数据更新也是尽力而为，由心跳最终修正。这种模式容忍临时不一致，但通过定期心跳和幂等重试保证系统收敛。开发者在构建分布式系统时，可参考此思路，用异步校正替代强一致事务，以提升可用性。
用量限额执行的异步与预聚合策略
D1 对存储和行数限额的执行采用异步处理与预聚合。存储用量通过队列批处理写入 Postgres，并用增量视图维护预计算账户总用量，避免扫描查询；行数限额则利用 ClickHouse 分析事件，并通过 Quicksilver 在边缘快速同步限制状态。这些做法将计费与限额检查移出关键路径，减少对中心数据库的压力。对于需要处理海量用量数据的平台，可借鉴此模式：用队列平滑写入，用预聚合加速读取，用边缘存储快速执行策略。
Q&A
D1 如何将查询热路径与控制平面分离？
D1 将查询热路径与控制平面分离，查询请求经边缘 Worker 直接转发到 SQLite Durable Object，不依赖中心 Postgres；控制平面操作（如创建、删除）则通过 Hyperdrive 访问中心 Postgres。
D1 数据库创建流程是怎样的？
创建 D1 数据库时，Edge API Worker 检查账户限额，生成唯一数据库 UUID 和 Durable Object ID，初始化 Durable Object，将元数据写入 Postgres，并将映射写入 Workers KV。整个过程有重试和自纠正机制。
D1 如何保证数据库状态的一致性？
D1 通过 Durable Object 定期心跳（每 30 秒加抖动）与控制平面同步，获取最新状态和账户限额。心跳可容忍稍旧数据，并能自纠正孤儿对象和 Workers KV 中的过期状态。
D1 如何执行存储用量限额？
D1 通过队列异步处理存储用量更新，使用增量预聚合表 account_database_stats 快速查询账户总用量。Durable Object 通过心跳读取该表，若超限则禁止增加存储的写入。
D1 如何执行行数用量限额？
D1 在边缘通过 Quicksilver 执行行数限额。查询执行时记录读写行数，事件发送到 ClickHouse，中心 Limiter 定期查询超限账户，并在 Quicksilver 设置键，Durable Object 检查该键以拒绝查询。
D1 控制平面使用了哪些数据存储？
D1 控制平面使用 Postgres 存储事务性元数据，Workers KV 缓存路由元数据，ClickHouse 进行用量分析，Quicksilver 用于边缘限额执行。
