过去一年中，OpenAI 的 Kafka 吞吐量在 30 多个集群中实现了 20 倍增长，其架构方案达到了 99.999%（五个9）的可用性标准。本文介绍他们的实现路径。
同时，笔者认为 OpenAI 的方案实际是把 Kafka 只用作存储层，通过 Producer 和 Consumer 两端的 Proxy 层来达到存算分离的目标。而这正是 Pulsar 存算分离的优势。OpenAI 在目标收益中关注的高可用性、高扩展性、易运维性等，都和存算分离的云原生架构紧密相关，这也是原文评论中 Pulsar 被重复提及的原因。
对于企业而言，选择 Apache Pulsar 不仅能够满足当前需求，还能为未来业务增长提供更大的灵活性和可扩展性。
推荐全文阅读。
OpenAI 的 Kafka 架构
- 实现 50 倍增长与 5 个 9 的可靠性 -
OpenAI 原文
2025-5-24
OpenAI’s Kafka throughput grew 20x in the last year across 30+ clusters.
OpenAI’s Kafka throughput grew 20x in the last year across 30+ clusters.
Their setup achieves five 9s (99.999%).
Here’s how they did it 👇
〰️〰️〰️〰️
🟩 𝗖𝗹𝘂𝘀𝘁𝗲𝗿 𝗚𝗿𝗼𝘂𝗽𝘀
They group clusters into groups. Each cluster lives in a separate region.
Through an upstream config service, users create logical topics that live in a group.
The logical topic has a physical topic in each cluster in the group.
This is well abstracted so users only think in terms of topics - not clusters or brokers.
〰️〰️〰️〰️
🟨 𝗣𝗿𝗶𝘀𝗺 - 𝗣𝗿𝗼𝗱𝘂𝗰𝗲𝗿 𝗣𝗿𝗼𝘅𝘆
A very simple producer proxy exposes just one endpoint - a gRPC ProduceBatch API.
Prism reduced their broker connections MASSIVELY. They used to get 50k connections per broker and run out of memory.
It also offers cross-cluster retries - if one region’s cluster fails, the proxy re-routes to another!
〰️〰️〰️〰️
🟧 𝘂𝗙𝗼𝗿𝘄𝗮𝗿𝗱𝗲𝗿 - 𝗖𝗼𝗻𝘀𝘂𝗺𝗲𝗿 𝗣𝗿𝗼𝘅𝘆
OpenAI uses Uber’s open source consumer proxy - uForwarder.
It changes consumption to a PUSH-based model. The proxy continuously pulls data from Kafka and pushes it to its subscribed consumers. 👌
This is also gRPC.
The proxy massively simplifies applications - they don't need to interact with a cluster, no need to configure/use a Kafka client, no need to setup complex auth and no need to manage offsets.
The proxy also offers some powerful features:
• automatic retries ✨
• dead letter queueing ✨
• multi-cluster consumption ✨
• no head of line blocking ✨
• parallelism greater than the number of partitions ✨
〰️〰️〰️〰️
🟥 𝗧𝗿𝗮𝗱𝗲𝗼𝗳𝗳𝘀
The careful reader may notice that this setup requires them to give up a few things, like:
⛔️ no transactions/idempotency
⛔️ no ordering
⛔️ no partitioning
Ordering, transactions and partitioning can be done downstream by other systems.
They embraced this principle - "Simple things should be simple, complex things should be possible."
As a result, they saw adoption skyrocket. 🚀
OpenAI intentionally took this tradeoff in order to get:
✅ vastly improved UX & integration for users
✅ 99.999% availability by routing around broken cluster
✅ improved scalability (efficient connections, high throughput per topic)
✅ easy maintenance
Another big reason for this architecture is decoupling the clients from the infrastructure. 💡
Because of the proxies, their clients are not coupled with the underlying clusters (infra).
This makes cluster maintenance (upgrade, reconfiguration, migration, decommissioning, addition) very easy. 👌
The UX improvement also cannot be overstated. They had 30+ clusters, using different Kafka engines/vendors, diff secrets/firewalls, each configured on an ad-hoc basis. 🫠
A big question users had was - “which cluster is topic X in? which one do I use?”.
This architecture solved it all, and they did it in less than a year 👌
原文：https://www.linkedin.com/posts/stanislavkozlovski_openai-kafka-activity-7331683326195331073-cxN6/
过去一年中，OpenAI 的 Kafka 吞吐量在 30 多个集群中实现了 20 倍增长，其架构方案达到了 99.999%（五个9）的可用性标准。以下是他们的实现路径：
集群分组策略
OpenAI 将集群按组划分，每个集群部署在独立区域。通过上游配置服务，用户可创建逻辑主题（logical topic）并关联至特定组。每个逻辑主题在组内的每个集群中对应一个物理主题（physical topic），这种设计通过高度抽象让用户只需关注主题本身，而无需关心集群或代理节点的底层细节。
Prism——生产者代理层
这是一个极简的生产者代理，仅暴露gRPC格式的ProduceBatch API端点。Prism的核心价值在于：
- 大幅减少连接数：此前每个代理节点需处理5万连接，常因内存耗尽崩溃，而Prism将连接集中管理；
- 跨集群重试机制：当某区域集群故障时，代理会自动将请求路由至其他集群。
uForwarder——消费者代理层
OpenAI采用Uber开源的消费者代理uForwarder，将传统拉取模式转为推送（PUSH）模型：代理持续从Kafka拉取数据并推送给订阅的消费者（同样基于gRPC）。这一设计让应用开发显著简化：无需直接对接集群、配置Kafka客户端、管理认证或偏移量（offset）。
代理还具备以下核心能力：
- 自动重试机制
- 死信队列（Dead Letter Queue）
- 多集群消费能力
- 无队首阻塞（Head-of-Line Blocking）
- 并行度超越分区数量
架构权衡与取舍
细心的读者可能注意到，这种设计需要牺牲部分功能：
- 不支持事务（Transactions）与幂等性（Idempotency）
- 不保证消息有序性
- 放弃分区特性（Partitioning）
但排序、事务和分区等需求可由下游系统处理。OpenAI遵循 “简单事情应极简，复杂事情需可行” 的原则，反而推动了架构的大规模落地，其核心收益包括：
- 用户体验与集成效率跃升
- 通过故障集群绕行实现99.999%可用性
- 提升扩展性（连接效率优化、单主题高吞吐量）
- 维护成本降低
此外，架构的核心优势在于客户端与基础设施的解耦：借助代理层，客户端无需依赖底层集群（如升级、重配置、迁移或扩容操作），使集群维护变得高效。用户体验的提升尤为显著——过去30多个集群采用不同引擎、认证机制和防火墙策略，用户常困惑 “主题X在哪个集群？该连接哪个？”，而新架构在不到一年时间内彻底解决了这类问题。
值得注意的评论
Julien Laurenceau（资深解决方案架构师）： “当对原生工具进行如此深度的改造时，我不确定是否仍有必要继续使用它。虽然未看到完整设计，但Apache Pulsar原生提供了分区与客户端间的代理层，而本文提到的代理可能在牺牲事务等功能的同时，也削弱了快速写入特性。我甚至怀疑端到端流水线是否还能保证至少一次送达（at-least-once）语义。若新项目没有Kafka遗留代码，建议不要采用此方案！”
Nitin Rajora（DLG资深SRE）：
“频繁的故障转移与无序消息并非所有场景都能接受。”Ben Gamble：
“这让我联想到Aklivity，它们也通过gRPC从Kafka流式导出数据。”Jordan Moore：
“他们在全球范围复制消息？这成本恐怕不低。”Félix GV：
“能否详细说明该架构如何实现超越底层分区的并行能力？”Fran Mendez：
“我欣赏他们通过API抽象底层基础设施的设计，这也优化了团队协作模式——平台团队真正承担起为消费团队简化开发体验的重任。通过限制部分功能（如分区），复杂度得以降低，用户只需更少认知成本即可使用Kafka集群，这对其特定场景而言是明智决策。”Penghui Li（StreamNative 流处理总监，Apache Pulsar PMC 成员）： "我同意Nitin的观点—这确实取决于具体的使用场景。这正是为什么Pulsar提供Key_Shared订阅模式：它允许您按键维护消息顺序，同时仍然支持消费者的可扩展性。"
以上中文翻译完。
为何 Apache Pulsar 被反复提及？
- Why Apache Pulsar -
成就与挑战
OpenAI实现了Kafka吞吐量20倍增长，并达到了99.999%的可用性，这一成就令人印象深刻。然而，他们为此付出了一些代价：
- 复杂的自定义代理层：构建和维护Prism(生产者代理)和uForwarder(消费者代理)需要大量工程资源
- 功能牺牲：放弃了事务、幂等性、消息顺序和分区控制等核心功能
- 高昂的基础设施成本：跨区域复制所有消息带来显著的存储和网络成本
- 维护负担：多个Kafka之外的自定义组件增加了系统复杂性和长期维护成本
正如评论中Julien Laurenceau所指出："在对原始工具进行如此大规模修改的情况下，我不确定继续使用它是否是个好主意！"
Apache Pulsar优势分析
Apache Pulsar作为新一代分布式消息和流处理平台，能够原生解决OpenAI面临的挑战，同时保留关键功能：
1. 原生多租户和集群抽象
Pulsar的设计理念与OpenAI的需求高度一致，无需自定义开发：
- 租户/命名空间层次结构：Pulsar原生支持多租户，通过租户和命名空间提供逻辑抽象，用户无需关心底层集群细节
- 统一API：统一的队列和流的访问接口
- 简化认证授权：集中化的认证和基于角色的访问控制
2. 内置代理层与连接管理
Pulsar架构天然包含代理层，无需额外开发：
- Pulsar Proxy：原生提供可扩展的代理层
- 连接复用：高效处理大量客户端连接，避免OpenAI遇到的50K连接内存溢出问题
- 协议适配：通过 KoP 无缝支持Kafka 协议
3. 地理复制与灾备
Pulsar提供比OpenAI自建方案更强大的地理复制能力：
- Geo-replication：内置跨区域的多集群复制功能，支持多种集群复制策略
- 灾难恢复：自动故障转移和恢复机制
- 区域感知路由：智能路由请求到最近的可用区域
4. 保留关键功能的同时提供简化体验
与OpenAI不同，Pulsar不需要牺牲核心功能：
- 事务支持：原生支持事务，确保跨主题的原子性操作
- 消息顺序：保证分区内消息顺序；Key-shared模式，保证单分区并发有序
- 灵活分区：支持自定义分区策略，同时提供简单接口
- 推拉结合模型：同时支持推模式和拉模式消费
5. 运维简化与成本优化
Pulsar架构设计显著降低运维复杂度和成本：
- 存储计算分离：BookKeeper提供高效存储层和节点之间的对等高可用，优化资源使用
- 弹性扩展：独立扩展存储和计算资源，避免过度配置
- 分层存储：热数据保留在高性能存储层，冷数据自动迁移到对象存储，降低成本
- 统一管理界面：简化集群监控和管理
客户价值对比
需求 | OpenAI Kafka方案 | Apache Pulsar方案 |
高可用性 | 通过自定义代理实现99.999% | 原生设计实现99.999%+ |
简化用户体验 | 需要自建Prism和uForwarder | 开箱即用的Pulsar Proxy |
多区域部署 | 自定义复制逻辑 | 内置Geo-replication |
消息推送效率 | 通过uForwarder 消费者代理实现 | 原生支持根据流量推拉结合的模式 |
消息顺序保证 | 已牺牲 | 完全支持 |
事务支持 | 已牺牲 | 完全支持 |
运维复杂度 | 高(多组件维护) | 低(统一平台) |
总体拥有成本 | 高(开发+维护+资源) | 低(开箱即用+资源优化) |
迁移路径建议
对于考虑类似存算分离云原生架构的企业，笔者建议：
- 评估现有需求：明确消息系统的核心需求，包括可用性、功能和扩展性
- 考虑Pulsar原生方案：利用Pulsar内置功能替代自建组件
- 渐进式迁移：利用Pulsar的Kafka协议适配器实现平滑迁移
- 验证关键指标：测试吞吐量、延迟和可用性，确保满足业务需求
结论
OpenAI 的 Kafka 架构展示了他们在面对挑战时的创新能力，但同时也暴露了传统消息系统的局限性。Apache Pulsar 作为新一代消息和流处理平台，能够原生提供 OpenAI 所需的所有功能，同时避免功能牺牲和维护复杂性。
笔者认为， OpenAI 的方案实际是把 Kafka 只用作存储层，通过 Producer 和 Consumer 两端的 Proxy 层来达到存算分离的目标。这正是 Pulsar 存算分离的优势。OpenAI 在目标收益中关注的高可用性、高扩展性、易运维性等，都和存算分离的云原生架构紧密相关，这也是原文评论中 Pulsar 被重复提及的原因。
对于企业而言，选择 Apache Pulsar 不仅能够满足当前需求，还能为未来业务增长提供更大的灵活性和可扩展性。正如评论中所指出的："请不要将其 (OpenAI 的自定义方案) 用于没有 Kafka 遗留代码的全新项目！
对于新项目，Apache Pulsar 提供了更现代、更完整的解决方案。
