演讲回顾｜谙流科技在 Kafka on Pulsar 之上的探索

本文整理自陶久明在 Pulsar Developer Day 2025 上的演讲，一起来看 Kafka on Pulsar (KoP) 的原理及产品化实践～

KoP 的基本原理

KoP 的实现依赖于 Pulsar 的协议插件机制，其核心是通过 Protocol Handler 接口在 Pulsar broker 中实现了完整的 Kafka 协议层。这使得 Kafka 客户端能够直接与 Pulsar 集群通信，而无须感知底层存储的差异，全部消息的存储与流转最终复用 Pulsar 成熟且强大的存储引擎。

具体到数据写入流程，则是来自 Kafka 客户端的请求首先被 KoP 协议层拦截和处理，随后被转换为标准的 Pulsar 协议格式，写入对应的 Pulsar Topic 中，并最终持久化到 BookKeeper 存储集群。

在多副本同步这一关键设计上，方案采用了 BookKeeper 自身的复制协议来替代 Kafka 依赖的 Raft 共识算法，这一改变显著优化了网络路径。传统的 Raft 协议需要经过领导者到追随者、再到另一个追随者的"两跳"确认，而 BookKeeper 协议允许数据从写入节点"一跳直达"多个存储节点，不仅降低了写入延迟，也提升了吞吐效率。

此外，得益于 Pulsar 原生的存算分离架构，整个系统的弹性扩缩容能力得到极大增强。计算层的无状态 broker 可以根据流量压力动态调整节点数量，这一特性在具有显著波峰波谷的业务场景中价值巨大，例如网约车平台面临的早晚高峰流量冲击，可以通过快速扩容 broker 来应对，而在平峰期则可缩容以节约成本。

在 KoP 与 Kafka 的映射关系上，设计了一套精巧的转换规则。Topic 映射并非简单的一对一，而是将 Kafka 的扁平化 Topic 名称映射到 Pulsar 层次化的"租户/命名空间/Topic"结构。在进行迁移时，为了保持对原有客户端的最大兼容性，可以通过在原始 Topic 名称前拼接 Pulsar 路径前缀（例如 persistent://public/default/original_topic）来实现平滑过渡。

消息 ID 的转换是另一个核心。Pulsar 的消息 ID 是一个复合结构，包含账本 ID、条目 ID、分区索引和批次索引；而 Kafka 的 offset 是一个简单的长整型。转换机制通过在消息被写入 Pulsar 之前，在其头部添加一个全局自增的 offset来解决，从而保证 Kafka 客户端读取到的 offset 顺序是连续且符合预期的。消费组的管理则通过模拟实现 Kafka 风格的 Group Coordinator 来完成，所有消费组的偏移量数据并非存储在 ZooKeeper 中，而是持久化在一个特定的 Pulsar 内部 Topic public/kafka/__consumer_offsets 里，这完全继承了 Pulsar Topic 的高可用和持久化特性。

KoP 的架构深刻体现了 Pulsar 的现代架构思想。

存算分离是架构的基石：计算层由无状态的 Pulsar broker 构成，负责协议处理、路由和计算；存储层则由独立的 BookKeeper 集群担当，专精于数据的持久化与复制。这种分离使得两层可以独立扩展和运维，提供了极大的灵活性。
多租户隔离通过"租户→命名空间→Topic"的三级结构实现，不同业务线的资源可以做到逻辑甚至物理层面的隔离，避免了相互干扰。
存储分层策略允许根据数据的访问频率进行智能化管理：热数据保留在高性能的本地存储上以保证低延迟访问；冷数据则可以通过 Pulsar 的分层存储功能自动卸载到成本更低的对象存储（如AWS S3）中，从而大幅降低长期存储的成本。

KoP 的核心优势

1）秒级扩容、资源利用率更高

传统 Kafka 的扩容过程涉及分区数据重新分配与迁移，这是一个耗时且可能影响服务可用性的操作。而 KoP 则实现了真正意义上的秒级弹性扩容 。这得益于其无状态的 broker 设计，新增的 broker 节点无需承载任何历史数据，可以立即加入集群分担负载 。在存储层，BookKeeper 的 ensemble select 机制能够自动将新写入的数据均衡地分布到所有可用的存储节点 （Bookie）上，包括新加入的节点，从而自动分摊存储压力，避免了传统方案中需要手动规划分区再平衡的复杂操作。

整个扩容过程中，所有 Topic 保持可读可写状态，服务等级协议不受任何影响。与之形成对比的是，Kafka 在分区再平衡期间，相关分区可能暂时不可用。

从资源利用率角度看，新老节点间的数据量会随时间推移自动趋于均衡：旧节点上的数据随着保留策略的生效而逐渐被清理，新数据则根据均衡策略写入包括新节点在内的所有节点，最终实现集群整体负载的均匀分布，有效解决了部分节点过载而其他节点闲置的资源浪费问题。

扩容效果是立竿见影且平滑的。新加入的存储节点可立即开始承接新的写入请求。旧节点上的存量数据不会发生迁移，而是随着时间推移，通过数据保留策略自然过期淘汰。新产生的数据则由系统自动写入负载较低的节点（包括新节点）。这种设计使得存储压力能够随着时间的推移，自动、渐进地从旧节点向新节点转移，直至整个集群各节点的负载达到动态平衡。

2）高性能低延迟

在性能方面，架构进行了多层次的深度优化。在主链路处理上，采用了无锁设计模型，避免了像 Kafka 那样在分区级别或类似系统在提交日志级别使用锁带来的争用开销，提升了并发处理能力。

在 IO 层面，BookKeeper 实现了读写 IO 的物理隔离，分别使用不同的磁盘设备或通道，确保了写入流与读取流互不干扰 ，提供了更稳定的延迟表现。通过排序提交等优化，提高了操作系统 PageCache 的命中率，并在顺序读取场景下智能预加载相邻消息，减少了磁盘 IO 次数。

多级缓存体系结合了Pulsar的broker层缓存和 BookKeeper 存储层的缓存，有效降低了直接访问持久化存储的延迟。

副本同步协议如前所述，优化后的路径较 Raft 更短，提升了复制效率。

内存管理采用池化机制，对读写内存进行精准控制，避免了类似 Kafka 完全依赖操作系统 PageCache 可能导致的缓存污染问题（例如大量写入操作挤占本应用于读取的缓存），使内存使用更高效、更加可预测。

3）小结

KoP 架构的核心优势有以下几个方面：

先进的架构设计：通过彻底的存储计算分离与云原生多租户支持，实现了资源隔离与运维简化，并保持了对 Kafka 协议的完全兼容，保护了既有投资。
革命性的弹性能力：支持秒级扩缩容且无需数据迁移，有效提升了资源利用率。
功能层面：继承了 Pulsar 的企业级特性，如开箱即用的跨地域复制（为业务提供灾备和多活能力）和灵活的消息保留策略（满足更精细化的数据生命周期管理需求）。
性能方面：通过多级优化实现了更低延迟与更高可靠性。

这些特性共同作用于成本优化，既通过弹性伸缩避免资源闲置，也通过冷热数据分层存储实现长期数据存储的成本效益最优。

谙流科技 ASK 的建设

作为 KoP 的技术实践者和产品化推动者，谙流科技的 ASK 已取得了阶段性成果。

1）稳定性

将开源技术转化为可靠的企业级产品，需要经过严苛的工程化锻造。谙流 ASK 基于开源 Pulsar 及 KoP 进行了深度改造，注入了商业化产品所必需的稳定性 与可靠性 基因。其中，混沌测试框架的建设是稳定性基石的保障。通过集成 ChaosMesh 等故障注入工具，系统性地模拟了生产环境中可能出现的各类异常场景，包括但不限于网络带宽限制、延迟、丢包，存储节点宕机、IO 异常，甚至 DNS 故障等。这套混沌测试流程已深度集成到持续集成管道中，实现了自动化验证。

测试体系构建得十分完善，涵盖从单元测试、集成测试到混沌测试、长时间压力测试的全方位验证。例如，在压力测试中，通过长时间高负载运行，能够有效暴露潜在的内存泄漏问题。在与开源版本的对比测试中发现，未经深度优化的版本在超大流量冲击下稳定性表现欠佳，会出现必然的宕机问题，而这正是产品化过程中必须攻克的关键障碍。针对这些问题，团队进行了大量关键修复。

在内存管理方面 ，解决了大流量下堆外内存溢出、内存提前释放导致的状态异常以及多处内存泄漏点。在语义兼容性上 ，重写了幂等性机制以精确对齐 Kafka 的行为，并修复了大量与事务相关的边界问题。在消费链路中，修复了 GroupCoordinator 在某些情况下丢失消费进度、Checksum 校验异常等严重影响可靠性的缺陷。此外，监控体系被完全重写，提供了更精准、更全面的 Metrics 指标，并完美支持主流的 Kafka Exporter，便于无缝接入现有监控栈。

目前，该产品已在严苛的生产环境中得到验证。每日处理的数据量达到 PB 级别，生产写入峰值达 13GB/s，消费读取峰值更是高达 39GB/s，管理超过 8000 个分区。在最能体现工程质量的稳定性指标上，集群已实现持续上百日的无故障稳定运行。

2）产品化

除了内核的稳定性，产品化建设同样重要。谙流科技提供了功能完善的管理控制台，极大简化了集群的运维与管理操作。高可用性设计贯穿始终，具备故障自动检测与恢复机制，并结合数据多副本存储，确保服务与数据的双重安全。

成功的客户案例是最有力的证明：在某客户大型生产环境中，集群承载的生产与消费总吞吐稳定在 50-60GB/s，每日处理数据量约 2PB，并已保持超过 100 天的稳定运行记录，充分证明了其产品化成熟度。

与此同时，谙流科技也在持续深化技术和产品实践。在协议扩展上，计划以 KoP 为蓝本，支持更多的消息协议，如物联网领域广泛使用的 MQTT 和金融领域常见的 AMQP，旨在打造一个统一的多协议消息平台。

存储优化是另一个重点方向，正在积极探索如 ZNS SSD 等新型存储介质，以期在更高的存储密度和更优的读写性能之间取得平衡。

云原生集成将持续深化，目标是与 Kubernetes 调度系统实现深度对接，实现更智能、更自动化的资源调度与管理。

智能运维是未来的重要能力，设想基于机器学习模型分析历史流量数据，预测未来的流量波动，并联动弹性扩缩容系统，实现"感知-决策-执行"的闭环自动运维。

谙流科技 ASK 演进方向

面向未来，ASK 的演进方向将聚焦于架构、云原生和功能三大领域。

架构优化方面，考虑引入如 Oxia 这样的新型元数据服务来替代 ZooKeeper，以支持更大规模的集群部署，并通过重构实现更高效的元数据 KV 存储与访问模型。

云原生适配是重中之重，计划深度适配各大公有云提供的原生存储服务，并对 BookKeeper 进行针对性改造，以更好地契合云环境的特性。

功能扩展上，将持续完善对 Kafka 生态的兼容，例如支持 ShareConsumer 等特性，并不断优化内核以提升吞吐量和降低延迟。

此外，云环境也带来了独特的挑战。例如，云盘自身通常默认提供三副本冗余，若与 BookKeeper 的数据多副本机制简单叠加，会导致存储效率低下。针对这一挑战，解决方案是探索直接利用云存储的高可靠冗余机制，在确保数据耐久性的前提下，合理减少应用层的副本数量，从而在性能、成本与可靠性之间做出更精细化的平衡设计。

现场 Q&A 摘要

KoP 的成本及收益分析 ：传统的集群规划往往需要保持较低的平均负载水位，预留大量缓冲资源以应对突发的流量高峰，这直接导致了硬件资源的长期闲置。采用 KoP 架构后，依托其强大的动态扩容能力，可以允许集群在常态下以更高的负载率运行。当流量激增时，系统能够快速、平滑地扩容，避免了为应对偶发峰值而进行的过度资源预留。这种模式不仅减少了因扩容缩容引发的数据再平衡操作本身的开销，更从整体上提升硬件资源的平均利用率，实现了显著的降本增效。

关于扩容机制：扩容的核心原理在于，新加入的存储节点初始写入吞吐为 0，但通过 BookKeeper 的流量自动分配机制，能够逐步、自然地接管集群中的部分写入流量。实施过程表现为，现有节点集群继续稳定服务，新增节点则以一种渐进式的、非侵入的方式吸收新增负载及部分均衡过来的负载。这种技术优势确保了服务在任何时候都不会中断，实现了真正的平滑过渡，并且能够支持 TB 级别数据规模的集群无缝扩容。

关于性能优化策略 ：基于实践，负载均衡采用分阶段、自动化的流量迁移策略，避免了瞬间切换对单个节点造成的冲击。实际部署中，单个存储节点曾实现超过 18000MB/s 的峰值写入吞吐。扩容时机的判断逻辑也变得更为智能化，可以基于写入吞吐的阈值，并结合数据总规模（TB 级）进行综合触发。真实部署案例表明，通过应用这一整套方案，可成功将集群的硬件资源利用率提升 200%，其在超大规模生产环境中的实用价值与强大潜力已经过充分验证。