Cloudflare 存储选型指南：KV、D1 还是 Durable Objects？

在开发 Web 应用时，我们总会面临数据存储的选择题。对于 Cloudflare 用户来说，这往往是在 KV、D1 和 Durable Objects (DO) 之间做取舍。

很多人觉得它们都是“存数据的地方”，但实际上，它们的设计初衷、一致性模型和应用场景截然不同。为了让你不再纠结，我们用一个最直观的类比来理解它们。

1. KV (Key-Value)：全球分布的“公告栏”

• 类比：你在全球各地的便利店门口都贴了一张“公告栏”。
• 特性：极致的读取速度，最终一致性。
• 适用场景：读远多于写，且对“实时性”要求不高的数据。
• 例如： 网站的配置信息、经过 CDN 缓存的图片元数据、重定向规则。
• 痛点：如果你在伦敦更新了公告，东京的公告可能要在几秒钟后才会更新（最终一致性）。此外，它不支持复杂的查询（比如“给我查出所有国家代码为 CN 的记录”），你只能通过 Key 一个个去取。

2. D1 (Serverless SQL)：严谨的“保险柜”

• 类比：一个管理规范、存取有序的“保险柜”，支持复杂的指令。
• 特性：强一致性，SQL 标准查询。
• 适用场景：需要关联查询、筛选、排序的数据。
• 例如： 用户的个人资料、商品订单、像 P2P 调度中那种需要按 country 和 last_seen 排序的节点列表。
• 痛点：相比 KV 的全球极致分布读取，D1 的数据处理需要走 SQL 引擎，会有极小的性能开销，但换来的是数据的高度准确和逻辑的灵活性。

3. Durable Objects (DO)：内存里的“专属小秘书”

• 类比：一个专属的“秘书”，他不仅能帮你记事，还能帮你做复杂的运算和协调。
• 特性：单实例强一致性，带内存状态。
• 适用场景：需要实时协调、强状态跟踪的复杂业务。
• 例如： 实时聊天室、多人协作编辑器、库存秒杀系统、P2P 握手中的全局协调逻辑。
• 优势：它是“活”的。数据被存放在内存中，且处理请求是串行的。这意味着你不需要担心多用户并发写导致的数据错乱。

快速选型对照表

怎么选？一个实战案例

假设你正在构建一个 P2P 图片分发网络：

1. 你需要存图片的基本信息（如 URL 和大小）？ 用 KV，因为它读取最快。
2. 你需要实时维护在线节点列表，并按国家筛选同国种子？ 用 D1。因为你需要 SELECT * FROM peers WHERE country = 'CN' ORDER BY last_seen DESC 这种逻辑，KV 做不到。
3. 如果你的 P2P 网络大到需要实时协调节点之间的握手，避免瞬间并发请求冲击？ 用 Durable Objects。它可以作为一个“全局协调者”，在内存中处理握手逻辑。

总结建议

• 如果你的需求是“查”，选 D1，SQL 的强大功能能解决 90% 的业务痛点。
• 如果你的需求是“存且读”，且数据极其简单，选 KV，它是最便宜且最快的。
• 如果你的需求是“协调”，需要保证一组数据在并发请求下绝对不会乱，或者需要极高的实时性，选 Durable Objects。

对于大多数中小型应用，KV+D1 的组合足以覆盖绝大多数业务场景。 不要因为 DO 看起来很高级就盲目使用，保持系统的简单性，往往比技术堆叠更重要。