当前云计算领域正经历深刻变革，对象存储与无服务器事件流的融合成为核心趋势。Cloudflare推出的R2对象存储基于事件流服务K2，以分层架构优势重塑数据流转逻辑：底层以对象存储为持久化基底，结合边缘网络、零成本弹性等特性，有效解决传统事件流在持久性与扩展性上的难题。数据显示，K2生产端延迟达P99约1秒，但端到端交付因长尾因素存在明显差距，引发多方对性能边界的争议。该架构既通过低延迟写入、原子偏移管理降低实现复杂度，又依托对象存储高持久性与易扩展特性实现独立扩展，为大规模流处理场景提供新方案。不过，其延迟下限、成本结构及场景适配性仍面临挑战，行业正围绕架构优化与性能提升展开深度探讨。

--91likeyou---

因此，Cloudflare 选择以已经能够提供持久性的基础设施为底座。R2 提供十一个 9 的持久性以及强一致性 API。将复制和共识机制下沉至存储层后，上层应用会变得更简单，计算与存储也可以彼此独立扩展。

对象存储无法追加写入，而日志恰恰依赖追加操作，这给实现带来了困难。K2 的解决办法是先在一项边缘服务的内存中暂存写入，短暂停顿以等待更多数据到达，再将整批数据写成一个分段文件。R2 的原子操作负责保证顺序并生成递增偏移量，因此完全不需要协调服务。这段等待时间正是延迟的来源。

Hacker News 上的讨论总体认可这种架构模式，但对性能数据提出了直接质疑。

评论者 psanford 概括了更广泛的趋势：

对象存储正在迅速成为新的核心数据基础。我们可以在 S3 上构建 Kafka，也可以在 S3 上构建 GitHub。

评论者 necubi 在讨论中表明自己是原文作者兼 K2 技术负责人。他认同，所有不要求 100 毫秒以内延迟的数据系统都在转向对象存储，并指出 K2 团队与 R2 团队相邻办公，双方可以协同演进产品。这篇文章署名为 Micah Wylde 和 Marc Selwan。

最尖锐的讨论来自一名正在使用公测版的用户。评论者 e1g 报告称，写入延迟低于一秒，但端到端交付延迟达到 p95 2.5 秒和 p99 7.5 秒，并询问这是否符合预期。一名代表团队回应的评论者表示，这一长尾延迟高于他们的预期，Consume API 的性能仍需改进，读取延迟方面的优化应该会在大约一周内显现。

一家竞争对手提出了不同看法。评论者 sensodine 披露自己供职于同一领域的 s2.dev。他认为，对象存储的应用空间可以扩展到 100 毫秒以下，并提到了 S3 Express 和 GCS rapid buckets 等速度更快的对象存储层。这两种服务都采用单可用区架构，因此为了实现区域级持久性，仍然需要进行仲裁写入。他这样描述其中的核心矛盾：

其中一个矛盾当然是，在将数据刷新到对象存储之前究竟应该等待多久——你必须直接在延迟与 PUT 操作的 API 成本之间作出权衡。

他表示，自己的服务使用有状态后端进程持续刷新多租户对象，每个对象包含来自多个数据流的记录。在不破坏单位经济模型的情况下，同一区域内的 p99 确认延迟可以达到约 50 毫秒。

定价引发了另一项实质性异议。评论者 nnx 认为，每生产 1GB 数据收取 0.04 美元，与其他云事件流服务相比价格合理，但消费数据也收取相同费用就显得偏高：

这意味着，在最简单的情况下，也就是只有一个消费者时，实际使用成本为 0.08 美元/GB；而采用扇出式消费者策略后，成本很快就会变得非常高。

这一点尤其重要，因为扇出正是 Cloudflare 为 K2 定位的应用场景之一。数据保留费用另行计算，每月每 GB 收取 0.02 美元；公测期间则不收取任何费用。

同一名评论者也从成本角度为 K2 辩护。他表示，相比 Google Pub/Sub，K2 的优势在于成本，尤其是在需要长期保留数据时。对象存储使其价格远低于自行托管或使用云托管的 Kafka，例如 Amazon MSK 或 Confluent，同时无需管理集群，并且在数据量增长时仍能保持稳定性能。他在同一条评论中再次说明了这项取舍：与依赖本地磁盘复制的系统相比，K2 的生产端和端到端 p99 延迟约为一秒。

多名评论者询问，K2 与采用相同对象存储模式的 AutoMQ 和 WarpStream 有何不同，并指出 Kafka 本身如今也支持无磁盘主题。其中一名评论者给出的答案并非来自 Cloudflare：K2 是为 Cloudflare 生态系统构建的，单独使用它并没有太大意义。

Kafka 兼容性已经列入路线图，K2 技术负责人也坦率解释了原因：

我个人并不是 Kafka API 的忠实拥护者。我认为，对普通用户而言，它过于底层；但对于需要深入集成到流处理引擎等其他系统的场景，它又过于高层。此外，要有效使用它，还需要复杂的客户端库。

K2 转而使用基于租约的消费 API。消费者轮询一个订阅，收到一批租期为五分钟的数据，随后可以确认消费、发送否定确认以请求重新投递，或者延长租约。他表示，这种设计可以提高读取并行度。当消费者是 Workers 时，这一点非常重要，因为 Workers 很容易并行扩展，但单个 Worker 的处理能力并不强。

在生产端，Worker 绑定可以发送批量数据，并指出失败是否值得重试：

const result = await env.EVENTS.send([ { content: new TextEncoder().encode( JSON.stringify({ event: "page_view", path: new URL(request.url).pathname, timestamp: Date.now(), }), ), headers: { "content-type": "application/json" }, },]);if (!result.success) { console.error(`Produce failed: ${result.error.message}`); return new Response("Failed to record event", { status: result.error.retryable ? 503 : 500, });}复制代码

K2 将数据表示为字节，编码方式由应用自行决定。

如果这些讨论具有代表性，那么争议的焦点并不是这种架构是否合理，而是延迟下限究竟在哪里。Cloudflare 公布的生产端延迟为一秒；用户测得的端到端长尾延迟是这一数字的数倍；竞争对手则声称，通过有状态刷新而非纯对象存储，可以在同一区域配置中实现 50 毫秒延迟。

公测版的限制为 10GB 存储空间，以及每条数据流 30MB/s 的生产吞吐量，用户可以填写表单申请提高限额。消息键和基于键的顺序保证、每秒数 GB 的并行写入、基于推送的 Worker 消费者、更低延迟的 Express 层以及 Kafka 客户端支持，都已列入后续计划。用户可以通过控制面板、API、Wrangler 或 cf 创建数据流；cf 是 Cloudflare 在同一周推出的命令行界面。

：

🔥 热词：#cloudflare使用ffmpeg推流 · #cloudflare一直正在验证 · #cloudflare卡在验证人机 · #cloudflare的zerotrust ios用不了 · #cloudflare正在进行安全验证 · #cloudflare端口映射mc服务器 · #cloudflare请刷新页面后重试 · #cloudflare哪些443端口开放的