传统远程过程调用（Remote Procedure Call, RPC）架构存在核心挑战：生产者和消费者须在规模与时间上对齐，否则事件丢失，多消费者独立处理时更甚，如电商后端交易事件需被分析与欺诈服务读取。通过解耦可解决，中间插入服务吸收写入。2026年10月1日推出Cloudflare（Cloudflare）的K2（K2）公开测试版，其为开发者平台持久事件流原语，事件存入有序日志供消费者按需读取。

传统 RPC 架构有个核心难题：生产者和消费者必须在规模和时序上对齐。如果生产者发送数据过多导致消费者无法处理，或消费者及下游服务不可用，事件就会丢失。多个消费者需要独立处理数据时，问题更突出。比如电商后端在交易完成时发出事件，需要由分析系统和欺诈检测服务读取。

解决办法是解耦生产者和消费者——在中间插入一个服务，吸收写入，同时让独立消费者按自己的节奏读取。

今天我们推出 Cloudflare K2 的公测版来解决这个问题。K2 是开发者平台上的持久化事件流原语。你发送事件到 K2 流，它将其存储为有序日志。消费者可用多种方式读取，比如将读取分散到一组消费者，或将全部消息投递给所有消费者。它完全无服务器，可扩展到海量数据，并支持长期保留，因此即使消费者停机很久也不会丢数据。

底层上，K2 在 R2 对象存储之上实现了分区持久日志，从而能扩展到巨大存储量。

如果想开始使用，可以按照这里的指南在几秒内创建第一个流。

边缘上的流

我们最初构建 K2 是因为自身需要在边缘有一个持久缓冲，先作为 Basin Pipelines 的摄取层。Pipelines 由基于拉取模式的流处理引擎驱动，意味着需要有其他系统在读、转换和写入 R2 前先存储事件。而且我们承诺一旦事件进入 Pipelines Stream 就绝不丢弃，所以该存储必须持久，可能在很长时间内不丢数据。

多数公司此时会部署 Apache Kafka。但 Pipelines 运行在 Cloudflare 边缘，覆盖超过 335 座城市的大量服务器。我们独特的架构意味着通常无法运行 Kafka 这类传统分布式系统软件，需要重新思考构建和运维方式。

尤其对于有状态服务，Cloudflare 全球基础设施带来挑战：机器分配到的资源片较小，机器相对短暂，网络常经公共互联网。但基础设施也有超能力：靠近全球用户，水平扩展能力惊人。

设计演变为 K2 的持久缓冲系统时，我们决定依赖已有的强大状态原语：R2。像 R2 这样的对象存储将极高持久性（11个9！）与强一致 API 结合。把复制和共识卸载到存储层，使应用层（即 K2）大幅简化、更便宜且更高性能。附带好处是计算与存储分离，各自独立扩展，从而能以低成本存储大量历史数据。

如何在对象存储上建日志？一个直接问题是 R2 与其他对象存储一样不支持追加（日志标准操作）。相反，我们必须写入完整的文件或段，且段要足够大以抵消读写开销。做法是在边缘服务内存中先累积写入，短暂停留等待数据到达后，将所有事件写成段文件。我们利用 R2 的原子操作实现有序和严格递增偏移，无需独立协调服务。

基于 R2 构建虽有诸多优势，但有一个缺点：较高的生产延迟。写对象存储比本地磁盘慢，且需等本地批次累积才开始写。K2 初始版本中，这导致第 99 百分位响应时间约有 1 秒生产延迟。

我们将在后续技术深潜中分享更多 K2 设计细节。

流、队列还是 Pipelines？

Cloudflare 已有若干异步投递原语，包括 Queues 和 Basin Pipelines。何时该用 K2 而非这些现有产品？

Queues 与 K2 Streams 有些表面相似：都接收事件、持久存储并投递给消费者。Queues 设计用于追踪需异步完成的昂贵或耗时工作项。例如图像处理应用可将用户请求入队，由实际图像处理服务处理。它们支持针对具体工作项的复杂逻辑，如重试、延迟和死信队列。

相比之下，K2 面向大规模数据移动、长期保留和扇出消费。消息以批次生产和消费——实现高效处理，但牺牲了消息级重试。批处理也导致比队列更高的生产延迟。

Basin Pipelines 是无服务器摄取服务。可发送 Pipeline JSON 事件，经转换写入 R2 或 Basin Catalog。若最终要将事件写入对象存储或 Iceberg 表，推荐 Pipelines；若做自定义处理或写到其他目标，则用 K2。

入门

使用 K2 需先创建流。账户下可建多个流应对不同用例或事件类型。可通过 cf、Wrangler、仪表板或 API 创建。

以收集和处理产品分析为例。首先用 cf 创建名为 app_events 且启用 HTTP 的流，返回 JSON 包含流 ID（如 d78b09ee1f50430e9ec92a8af92b0231）、保留时间 604800 秒、endpoint 等信息。

流创建后，可通过 HTTP API 或 Worker 绑定生产事件。例如在 Worker 中调用 env.EVENTS.send 发送 JSON 编码的批次，失败则返回错误。

K2 将数据表示为字节，因此可使用任意适合应用的格式或编码。

流中有事件后，可创建订阅。订阅在消费者间分配工作，实现读取并行——扩展到多个读取者以处理单服务器无法承担的负载。

可通过 HTTP API 创建订阅，例如向流的 /subscriptions 端点发送 POST 指定名称和 start_at 为 earliest，返回订阅 ID（如 ee13f761783d3823a447a47b572ebf76）。

订阅创建后，各消费者可轮询。例如调用 /subscriptions/{id}/consume 并指定 workerid 和 maxrecords，返回含 batch_id、租约到期时间和记录数组的响应，记录包括时间戳与 base64 内容。

客户端调用 consume 时，会获得该批次事件 5 分钟的租约。客户端可做三件事： - ack 批次，标记为已处理且不再投递 - nack（否定确认），表示处理失败希望重新投递 - extend 租约，若需更多处理时间

可通过向 batches/{batch_id}/ack 发送 POST 来确认。

这是 K2 的一种消费方式：在多个消费者间拆分工作，各得部分数据。另一种是为每个消费者建独立订阅（发布/订阅模式），这样每个消费者看到全部消息。也可混合两种，拥有多个独立消费者池。

完整 API 细节参见 K2 文档。

定价与可用性

K2 目前对配备 Workers Paid 订阅的账户开放公测，限制如下： - 存储最多 10GB - 每流生产速率 30 MB/s

如需更高限制，可通过 Discord 联系团队或填写限额提升表单。

公测期间 K2 使用免费。开始计费后预计定价为：产生数据每 GB 0.04 美元，消费数据每 GB 0.04 美元，保留数据每 GB 每月 0.02 美元。

下一步

未来几个月 K2 路线图包括： - 更高写入并行度，达多 GB/s 流 - 消息键和基于键的顺序保证 - 基于推送的 Worker 消费者 - 更低生产和端到端延迟的 Express 层级 - 直接支持 Apache Kafka 客户端

期待看到你在 K2 上构建的东西！请在 Cloudflare Discord 上分享反馈。

多数人认可基于对象存储简化流处理模型的价值，少数人则担忧非标锁定、与现有 S3 上 Kafka 方案同质化及 Cloudflare 工程节奏的安全性。

认可简化流模型并期待 Kafka 兼容

• 流系统常因分区等概念复杂易错，将单个流做得廉价易用是巨大简化；同时期待支持 Kafka API，让企业低成本用上全无服务器兼容服务。（认可度：较多人）
• > 流系统强大却复杂，把单个流做得廉价易用是极大简化，也好奇托管按键排序怎么实现。（@addisonj）

看好对象存储优先与无状态架构

• 对象存储正成为核心数据底座，基于 S3 构建流式系统可避免管理磁盘，期待存储接口扩展以支持更多场景。（认可度：较多人）
• > 对象存储正快速成为新核心数据底座，比起管理带磁盘的系统，我更想要无状态服务器加一个存储桶。（@psanford）

担忧非便携标准与供应商锁定

• 产品虽有趣，但不愿依赖非行业通用标准，担心可移植性带来长期风险。（认可度：较多人）
• > 产品很有趣，但我总不愿构建在任何非可移植行业标准的东西上。（@thepaulmcbride）

质疑与现有 S3 流式方案缺乏差异

• 指出 AutoMQ、WarpStream 等早已是构建在 S3 上的无服务器方案，Kafka 自身也支持 S3 卸载，怀疑多区域等新优势的可行性。（认可度：少数人）
• > 这方案与 AutoMQ 和 WarpStream 有何不同？后者已是 S3 上的无服务器方案，Kafka 也能卸载数据到 S3。（@kirillkosolapov）

担心 Cloudflare 过快发布节奏下的安全

• 认为发布新产品节奏近乎狂热且员工更少，严肃客户应担忧其基础设施安全与质量。（认可度：少数人）
• > 若我是严肃客户会非常担心基础设施安全，大模型能加速编码但这么快发布、人还少，令人不安。（@loufe）

有价值的补充

• 冷知识纠正：并非没有主流对象存储支持追加写，Azure Blob Storage 从一开始便支持该操作。（@senderista）
• 竞品盲区：文中未提及最接近的竞品 AWS Kinesis，其定位与 K2 最为相似。（@senderista）
• 定位厘清：有用户借助模型总结，K2 用于记录事件、多系统读取与回放（类 Kafka 架构），而 Cloudflare Queue 侧重任务必达、重试与延迟作业，二者互补而非替代。（@ipkstef）