Cloudflare在R2上做了个事件流服务，想把Kafka替掉

Cloudflare把K2放出来公测，这是一项基于R2对象存储的无服务器事件流服务，它的底座是R2里的分区持久化日志。Cloudflare公布的数据是，生产端延迟p99约一秒。公开测试显示，端到端交付速度比这个数字更慢，延迟主要花在内存里攒批的那段时间。

这个服务的起点是自家需求。Cloudflare的Basin Pipelines需要一个持久化位置暂存事件，等基于拉取模式的处理引擎读取并转换。多数公司遇到这种需求会选Kafka，但Pipelines的边缘网络覆盖335个以上城市，用的算力是临时机器上分出的一点资源，连接走公共互联网，Kafka的设计没考虑这些条件。

底座选在了已经能提供持久性的地方。R2给出11个9的持久性和强一致性API。把复制和共识机制下沉到存储层之后，上层应用会变简单，计算和存储也可以各自独立扩展。这个思路本身不新，新的是把它用在日志这种对顺序极敏感的负载上。

难点在于对象存储不支持追加写，而日志恰恰依赖追加。K2的处理办法是先在边缘服务的内存里暂存写入，短暂停顿等待更多数据到达，再把这一批数据落成一个分段文件。顺序和递增偏移量由R2的原子操作保证，因此完全不需要额外的协调服务。延迟也就来自这段等待。

Hacker News社区的反应是，架构方向认可，性能数字遭到直接质疑。有评论概括了更大的趋势：对象存储正在变成新的核心数据底座，S3上能搭Kafka，也能搭GitHub。这条判断成立与否，取决于延迟能被压到多少、成本能省下多少。

判断K2适不适合自己，看的是场景。在边缘节点上跑临时计算、不想为一个日志系统单独维护集群、能接受一秒级延迟的，可以用；需要毫秒级延迟、或者依赖强事务和精确一次语义的，仍然要靠原来的消息中间件。把延迟换成成本和弹性，是这个服务全部取舍的核心。