对象存储正在「吃掉」Kafka：Cloudflare 用 R2 重做事件流，延迟换成本

过去十年，提到「事件流」，大多数架构师的第一反应是 Kafka。但 Cloudflare 在做一个不太一样的尝试：把事件流建在对象存储上，用大约一秒的延迟，换更低的成本和更强的弹性。

一分钟速览

• Cloudflare 推出无服务器事件流服务 K2 公测版，底层是在 R2 对象存储中运行的分区持久化日志。
• 生产端延迟的 p99 约为 1 秒；公测用户报告的端到端交付延迟为 p95 2.5 秒、p99 7.5 秒。
• K2 最初是 Basin Pipelines 的底层管道，需要在覆盖 335 个以上城市的边缘网络中暂存事件。
• R2 提供十一个 9 的持久性和强一致性 API，复制与共识机制下沉到存储层。
• 对象存储不支持追加写入，K2 通过在内存中暂存、批量写入分段文件来实现日志追加语义。

为什么不能直接用 Kafka

Kafka 的设计前提是：一堆稳定的服务器、相对可靠的网络、可以长期运行的 broker。Cloudflare 的边缘计算场景恰好相反：计算资源是临时的，机器分布在几百个城市，连接走公共互联网，随时可能断。

在这种环境里跑 Kafka，运维复杂度会急剧上升。broker 需要协调，分区需要复制，消费者需要管理偏移量。而边缘节点可能几分钟就销毁，根本没时间做这些事。

K2 的选择是「把复杂性下沉」。R2 已经提供了持久性和强一致性，复制和共识由存储层负责，上层应用只需要解决「怎么把日志追加进去」。这也是为什么它敢说「不需要协调服务」。

对象存储不能追加，怎么办

日志的本质是追加：一条一条往后写，顺序不能乱。对象存储的本质是覆盖：一个对象写完就不可变，要改只能整个替换。两者天生不匹配。

K2 的解决办法是批处理：先在边缘服务的内存里暂存写入，短暂停顿，等更多数据到达，再把整批数据写成一个分段文件。R2 的原子操作负责保证顺序并生成递增偏移量，因此不需要额外的协调服务。这段等待时间，正是延迟的来源。

换句话说，K2 不是「实时流」，而是「微批流」。它用一点延迟，换来了无协调、易扩展、成本低的架构。对日志、指标、审计、事件归档这类场景，一秒的延迟通常可以接受；对高频交易、实时竞价这类场景，则完全不够。

公测数据暴露的真实取舍

Cloudflare 公布的生产端 p99 延迟约为 1 秒，但公测用户的实测显示，端到端交付延迟达到 p95 2.5 秒、p99 7.5 秒。这个差距并不意外：生产端只算「写进去」，端到端还要算「读出来、传过去、被消费」。批处理窗口、网络抖动、消费者拉取节奏，都会拉长尾延迟。

团队回应称，这一长尾延迟高于预期，正在优化。这种坦诚值得肯定，但也提醒使用者：不要把「生产端延迟」当成「端到端延迟」。选型时，最好用自己的真实负载压测，而不是只看厂商的基准数字。

成本侧的逻辑则很清晰。对象存储的单价远低于块存储和专用消息队列，而且按量计费、无需预置容量。对流量波动大的业务来说，这种弹性比低延迟更值钱。

趋势洞察

「对象存储正在成为新的核心数据基础」，这句话在开发者社区里越来越有共鸣。已经有人在 S3 上构建 Kafka，在 S3 上构建 GitHub，现在又有人在 R2 上构建事件流。对象存储的简单接口、低成本和高持久性，正在吞噬一批传统中间件的生存空间。

但「吞噬」不等于「替代」。Kafka 仍然适合低延迟、高吞吐、强顺序的实时场景；对象存储适合大批量、可容忍延迟、成本敏感的归档和分析场景。未来的架构，很可能是两者并存：热数据走 Kafka，温冷数据沉到对象存储，中间用分层工具衔接。

对国内云厂商来说，这也是一个值得关注的方向。对象存储的竞争已经从「容量和价格」转向「能不能在上面长出数据系统」。谁能让开发者在对象存储上更方便地构建日志、队列和表，谁就能吃到下一波数据基础设施的红利。