KV 是一种全局、低延迟的键值数据存储。它将数据存储在少量中心化数据中心，访问后在 Cloudflare 数据中心中缓存这些数据。
KV 支持极高的读取量和低延迟，因此可以构建得益于 KV 内置缓存和全球分布的动态 API，这些 API 能够扩展。 未命中缓存且需要访问中心存储的请求可能会遇到更高的延迟。
当你向 KV 写入时，数据会写入中心数据存储。数据不会自动发送到每个位置的缓存。
某个位置的首次读取没有缓存值。必须从最近的区域层读取数据，然后是中心层，最后降级到中心存储以进行真正的全局冷读取。虽然首次全球访问较慢，但后续请求会更快，尤其是当请求集中在单个区域时。
来自同一位置的频繁读取会返回缓存值，而无需从其他地方读取，从而获得最快的响应时间。KV 会在缓存过期前通过从上层缓存和中心数据存储刷新来仔细更新缓存值。
在后台从上层和中心数据存储刷新时，会谨慎进行，以确保正在访问的资源继续从缓存提供服务，不会出现停顿。
KV 针对高读取应用进行了优化。它将数据集中存储，并使用混合推送/拉取式复制将数据存储在缓存中。KV 适合写入相对不频繁，但需要快速、频繁读取的使用场景。不常读取的值会从其他数据中心或中心存储拉取，而更受欢迎的值会缓存在请求它们的数据中心中。
要提升 KV 性能，可将 cacheTtl 参数 从默认的 60 秒调高。
KV 通过缓存 ↗实现高性能，这使得读取与写入最终一致。
更改通常在执行更改的 Cloudflare 全球网络位置立即可见。在其他全球网络位置，更改可能需要最多 60 秒或更长时间才能可见，因为其缓存的数据版本会超时。
表示键不存在的负向查找也会被缓存，因此注意到值被创建与值被更改存在相同的延迟。
KV 通过最终一致性实现高性能。在做出更改的 Cloudflare 全球网络位置，这些更改通常立即可见。但是，这并不保证，因此不建议依赖此行为。在其他全球网络位置，更改可能需要最多 60 秒或更长时间才能可见，因为其缓存的数据版本会超时。
在最近读取过给定键先前版本（包括指示键不存在的读取，这些读取也会在本地缓存）的位置，更改的可见性需要更长时间。
实现写后写一致性的方法是，将给定 KV 键的所有写入通过相应的 Durable Objects 实例发送，然后在其他 Workers 中从 KV 读取该值。如果你需要对写入有更多控制，但对上述 KV 读取特性感到满意，这很有用。
Workers KV 是一种最终一致性的边缘键值存储。这使其非常适合读取密集型、高度可缓存的工作负载，例如：
- 提供静态资源
- 存储应用配置
- 存储用户偏好
- 实现允许列表/拒绝列表
- 缓存
在这些场景中，Workers 在最接近用户的数据中心中调用，Workers KV 数据会在该区域缓存以供后续请求使用，从而最小化延迟。
如果你有写入密集型的 Redis ↗ 类型工作负载，每秒对同一键更新数十或数百次，KV 可能不是理想选择。 如果你可以重新审视应用如何写入单个键值对，并将写入分散到多个独立键上，Workers KV 可以满足你的需求。 或者，Durable Objects 提供具有更高每键写入速率限制的键值 API。
请参阅数据安全文档，了解 Workers KV 如何保护数据。