Cloudflare KV 作为全球分布式商店出售，该描述在技术上是正确的。它遗漏的是“全局分布式”完全适用于读取，仅部分适用于写入 - 最多 60 秒的延迟会改变您应该如何使用它的一切。
当您向 KV 写入密钥时，写入的内容会发送到中央存储。从那里，它传播到所有 Cloudflare 存在点 - 分布在全球的 300 多个 PoP。这种传播不是瞬时的。官方文档指出所有 PoP 最多需要 60 秒才能收到新值。在此窗口期间，在法兰克福运行的 Worker 可以返回旧值，而在圣保罗的 Worker 已经看到新值。如果同一区域的两个 Worker 其中之一尚未收到更新，则可能会出现分歧。
这就是最终一致性。 Cloudflare 清楚地记录了这种行为，但“全球分布”这个短语足够诱人，以至于许多团队在调试生产中的错误之前不会阅读该部分。
阅读中会发生什么
KV 中的读取有两条路径，它们之间的差异对延迟很重要。当 Worker 执行 0 时，运行时会检查该密钥是否缓存在为请求提供服务的 PoP 中。如果是（大多数热键都是如此），读数将在亚毫秒内直接从 PoP 内存返回。这是一条快乐的道路，也是 KV 读取速度异常快的原因。
如果该密钥未缓存在该 PoP 中（因为它是新密钥、因为它是最近写入且尚未传播，或者因为 PoP 根本没有接收到该输入），则运行时会搜索中央存储。这会增加大约 20 毫秒。这并不引人注目，但它是可测量的，当钥匙冷时你会看到这个数字出现在痕迹中。
令人惊讶的细节是：不能保证读你所写的内容。您编写一个密钥并立即尝试在同一个 Worker 调用中读取它。读取可能会返回之前的值。这种行为是有记录的并且是有意为之的——它是 PoP 缓存架构的直接结果。如果您需要读您所写的内容，KV 并不是适合该流程的工具。
KV 是为哪些工作负载构建的
当您知道 KV 架构解决的问题时，它就非常有意义：以低频写入数据并以非常高的频率读取数据。经济模型强化了这种模式。每月免费阅读 1000 万次之后，每百万次阅读费用为 0.50 美元。在第一个免费百万之后，写入费用为每百万 0.50 美元。在免费套餐中，每天有 10 万次读取，而每天只有 1000 次写入。
成本和限制指向相同的工作负载：少写，多读。功能标志是典型的例子。带有产品标志的 JSON 文件每天最多更改几次。但世界上每个 PoP 中每个 Worker 的每个请求都会读取它。对于一个标志来说，60 秒的传播是可以接受的——您不需要地球上的每个用户都在同一毫秒内看到该功能。读取次数（每月可能数十亿次）以最低成本进行缓存。
同样的推理适用于呈现的 HTML 模板、应用程序配置、更新频率较低的目录数据以及具有定义的 TTL 的会话令牌。您写入一次，读取数万次，KV 会提供缓存延迟。
KV会在哪里背叛你
任何需要立即一致性的工作负载在通过 KV 实现时都会产生错误。最常见的情况是状态可变的用户会话。用户退出；你在KV中写入无效会话标志；在接下来的 60 秒内，不同的 PoP 仍然可以使用旧令牌对请求进行身份验证，因为它没有收到更新。
准确的计数器是另一个失败点。 KV 没有原子操作——没有比较和交换，没有原子增量。两个同时读取同一计数器的 Worker 将读取相同的值，独立递增，并且其中一个增量将丢失。对于需要精确的速率限制计数器，KV 是错误的工具。对于这种情况，存在耐用对象。
根据请求更改的数据也不适合。如果对用户的每次响应都会更改 KV 中的值，则您需要为容量巨大的每百万次写入支付 0.50 美元，中央存储中每次写入确认的延迟约为 150 毫秒，再加上传播延迟。成本以一种没有经济意义的方式扩展，并且写入延迟将出现在请求的 p99 尾部中。
为了实现每键的即时一致性和低写入延迟，带有 Sessions API 的 D1 是 Cloudflare 的当前路径。对于需要原子操作的共享状态，持久对象。
没有幻想的成本模型
免费套餐对于实验来说很慷慨，但对于任意数量的生产来说却很有限。每天 100,000 个读数相当于每秒 1 个以上的持续请求 — 具有合理流量的真实应用程序会在几分钟内完成。
在付费层，变化在于阅读实际上是免费的。每百万次读取 0.50 美元足够便宜，如果您的工作负载是适当的读取量，则不会在帐单上显示为相关行。写入费用为每百万 0.50 美元，每月 100 万次免费，涵盖大多数配置标准和标志，无需大量成本。
可能会让您感到惊讶的是存储空间：除了第一个免费 GB 之外，每月每 GB 还需 0.50 美元。对于小值——配置 JSON、令牌、标志——你几乎不会触及这个限制。对于那些考虑在 KV 中存储相当大大小的二进制文件（每个值的限制为 25MB）的人来说，存储成本开始出现。对于大文件，R2 的价格为 0.015 美元/GB 更有意义。
KV 能很好地解决什么问题，不能解决什么问题
KV是一款高性能读取工具，偶尔写入。当您选择此模型时，它可以为热读取提供亚毫秒级延迟、无需设置复制的自动全局分发以及有利于大量读取的定价模型。
错误不在于使用 KV——而是把它当作一个通用数据库来使用。没有任何工具可以取代正确的工作负载诊断。如果每个用户的数据频繁更改、需要原子性或需要立即一致性，那么 KV 将无法提供 — 并且您会在生产中而不是开发中发现这一点。
另请阅读
- [生产中的 KV：有效的模式和一开始就具有误导性的模式2
- 【KV中的缓存失效：没人优雅解决的问题3
- [速率限制、功能标志和分布式配置的 KV：它在哪里工作以及在哪里中断4
- [Cloudflare D1：边缘的 SQLite 数据库 - 以及为什么“边缘”的含义并不像看上去的那样55
- [Cloudflare Workers 与 Pages：选择之前最重要的区别6
- [KV、R2 与 Cache API：何时使用每个 Cloudflare7 存储层