2025 年 6 月的 Confluent Current 大会上，OpenAI 的实时基础设施团队连续做了两场分享，完整披露了他们如何在一年内将 Apache Kafka 吞吐量提升 20 倍、可用性从不到 3 个 9 拉到 5 个 9（来源：OpenAI at Confluent Current 2025）。更值得拆解的是他们为此放弃了什么：排序、事务、分区处理，这些 Kafka 最核心的语义。

1 37 个集群、5 万连接、3 个 9 都保不住

2024 年上半年，OpenAI 的流处理平台已经被几乎所有产品团队采用，数据摄入、异步处理、服务间通信，ChatGPT 的后端链路上到处都是 Kafka。但平台本身的状态用"混乱"来形容并不过分。

当时 OpenAI 内部有超过 30 个独立的 Kafka 集群，大多数是各产品团队在不同时期临时自建的。这些集群配置互不兼容，部分甚至运行在不同的 Kafka 兼容引擎上。一个新加入的工程师面对的第一个问题不是"怎么用 Kafka"，而是"我的 topic 在哪个集群上"。产品团队接入 Kafka 要花数天甚至数周，本来几小时就该搞定。

扩展性问题更为严峻。OpenAI 的外部服务有大量副本来承载 ChatGPT 的流量，每个副本都独立连接 Kafka 集群。更棘手的是，OpenAI 主要使用 Python，而 Python 的 GIL 限制意味着单个 pod 内需要运行多达 50 个独立进程来榨取并行性能，每个进程都会建立自己的 Kafka 连接。结果是某个集群的单个 broker 承受了 50,000 个并发连接，JVM 内存直接打满，连接不断被丢弃。这不是连接风暴，而是稳态下的常态过载。

可用性方面，Kafka 集群是许多内部服务的单点故障。一次区域故障或集群崩溃就意味着面向外部的产品硬停机或数据丢失。整个平台连 3 个 9 都撑不住，对于支撑 ChatGPT 的基础设施来说，这是不可接受的。

这些问题都还能忍。真正卡死他们的是基础设施团队根本动不了：产品服务与具体的 Kafka 集群紧耦合，想做集群迁移、版本升级、甚至只是调整配置，都需要协调大量产品团队。

2 在 Kafka 之上再建一层

要打破这种耦合，OpenAI 选择了一个经典的架构手段：在客户端和 Kafka 集群之间加一层代理，让所有服务都通过代理交互，而不是直连集群。

首先要解决的是连接数爆炸。他们构建了 Prism，一个极简的 gRPC 服务，只暴露一个 ProduceBatch 端点。生产者把消息和目标 topic 发给 Prism，由 Prism 负责路由到正确的底层 Kafka 集群。用户不再需要知道哪个集群承载哪个 topic，也不需要配置集群凭证和防火墙规则。他们甚至开发了一个叫 Photon 的客户端库，让接入简化到"import 库，调用一个函数"的程度。单个 Prism pod 服务多个客户端 pod，Kafka broker 的直连数大幅收敛。

连接数收敛了，但集群耦合还在。Prism 真正强大的地方在于多集群路由：同一个 topic 可以由多个 Kafka 集群服务，Prism 负责在这些集群之间做负载均衡。如果某个集群的发布请求失败，Prism 会透明地重试到另一个集群；如果某个集群长时间降级，熔断器会将其标记为不可用，自动绕过。配合 Cluster Group 的概念（一组包含相同 topic 的 Kafka 集群集合），高可用 Cluster Group 将多个集群部署在不同区域，Prism 写入任意一个健康的集群。所有这些对生产者完全不可见。

uber UForwarder for kafka迁移过程本身设计得很巧妙：在新集群上创建 topic，UForwarder 同时从新旧集群消费，Prism 逐步将写入切换到新集群，旧集群数据过期后下线。单次迁移约 30 分钟完成流量切换，对用户完全透明。最终成果：

当然，把数据写到 S3 不是没有代价。对象存储的 API 调用延迟高于本地磁盘，尾延迟（p99/p999）需要额外优化；高频小批量写入场景下 S3 API 调用本身的成本也不能忽略。这是一个不同的工程权衡点，不是银弹。

存储成本方面，传统 Kafka 的三副本复制叠加 EBS（Elastic Block Store）自身的冗余复制，实际存储冗余度远高于对象存储的纠删码方案。存算分离架构消除了 broker 间的副本复制，数据直接写入 S3，由对象存储的纠删码保证持久性，存储成本显著降低。具体的成本对比数据可参考 AutoMQ 官方 benchmark。

5 路标与终点

在 2025 年 6 月 Confluent Current 的 Q&A 环节，有人问 OpenAI 的工程师怎么看 Diskless Kafka，回答是"非常积极地在思考和探索"。当你已经为绕过传统 Kafka 的限制付出了这么大的工程代价，引擎层的根本性演进自然是最有吸引力的下一步。OpenAI 证明了即使放弃排序和事务也能让 Kafka 在超大规模下工作，但这个代价本身就是最好的论据：引擎层的演进已经不是可选项。对于正在规划下一代流处理基础设施的团队来说，问题只是现在就在引擎层解决，还是先建一层代理再说。

如果你也正在为各种 Kafka 挑战而烦恼，可以立即通过 AutoMQ 官网或者 Github 体验和尝试我们的产品。

今日好文推荐