vivo 移动互联网业务为全球超过 4 亿用户提供应用商店、短视频、广告等服务，其分布式消息中间件平台承担了实时数据接入与分发的关键角色，日均处理数据量达十万亿级别。面对业务规模的持续增长，vivo 在消息系统架构演进中通过引入 Apache Pulsar，有效解决了原有 Kafka 架构在多集群管理、弹性扩缩容和海量分区场景下面临的诸多瓶颈。

业务痛点与挑战

随着 vivo 业务流量的数十倍增长，原有基于 Kafka 的消息系统逐渐显露出架构局限性。Topic 和分区数量的持续增加严重影响了集群性能，大量分区导致磁盘随机读写加剧，违背了 Kafka 依赖顺序读写实现高性能的设计初衷。集群规模扩张后，资源组隔离与集群拆分的运维成本显著上升，且 Kafka 无法实现动态扩缩容，机器资源利用率低。在面对突发流量时，扩容速度缓慢，流量均衡耗时较长，消费端性能过度依赖分区数量，造成元数据急剧膨胀。此外，集群基数增大导致硬件故障频发，且故障直接传导至客户端，缺乏有效的中间容错层。

技术选型

在综合评估集群稳定性、扩展能力和运维成本后，vivo 选择引入 Apache Pulsar 作为新一代消息中间件。Pulsar 的存算分离架构带来显著优势：无状态 Broker 支持快速扩缩容，存储层基于 BookKeeper 实现数据均匀分布和高可用保障。其独有的 Bundle 机制能够以有限的逻辑单元管理海量 Topic，有效避免元数据膨胀问题。Pulsar 支持多种消费模式（Exclusive、Failover、Shared、Key_Shared），消费能力扩展不再完全依赖分区数量，Shared 模式可实现多个消费者并行处理，Key_Shared 模式则在共享消费的同时保证消息顺序性。这些特性使 Pulsar 能够更好地应对 vivo 业务场景中的流量突发、故障恢复和弹性扩展需求。

业务实践与优化

在落地实践中，vivo 重点优化了 Pulsar 的 Bundle 管理机制，通过合理设置 Bundle 数量范围和拆分策略，确保流量在 Broker 间的均衡分布。针对数据管理，团队优化了 Ledger 翻转参数，防止单个 Ledger 过大导致的数据存储不均衡问题。建立了统一的数据保留策略，将 TTL 与 Retention 周期对齐，简化数据过期处理流程。在监控方面，vivo 构建了基于 Prometheus + Kafka + Druid 的指标采集和存储体系，开发了包括 Bundle 分布、读写延迟 P95/P99、网络负载等在内的多维监控指标。

针对实际应用中发现的负载均衡和客户端性能问题，团队进行了系列优化：调整负载均衡参数，将节点流量偏差控制在 20% 以内；通过增加分区数量改善 Bundle 分配均衡性；优化客户端发送参数配置，显著提升发送性能；实施 "能者多劳" 的发送策略，解决单个分区阻塞影响整体发送性能的问题。这些优化措施使得 Pulsar 集群在 vivo 环境中稳定支撑千亿级消息流量，有效应对各类异常场景，为业务提供高可靠、低延迟的消息服务。

滴滴大数据运维实践

滴滴大数据团队于 2021 年 1 月开始调研 Apache Pulsar，同年 8 月正式上线首个 Pulsar 集群，支撑数据开发平台和同步中心的数据通道同步任务。经过两年多的稳定运行，Pulsar 成功替代了原有的 DKafka（基于 Kafka 2.12-0.10.2.0）系统，有效解决了长期困扰团队的运维难题，实现了性能、成本和可靠性的全面提升。

业务痛点与挑战

滴滴大数据原有的 DKafka 系统面临多重运维挑战。首先是磁盘 IO 瓶颈问题，当 Broker 承载成百上千个 Topic 分区时，磁盘写入由顺序变为随机，导致性能急剧下降，生产消费耗时显著增加。其次是集群容量限制，尽管团队曾尝试用 SSD 替代 SATA 盘，但成本高昂且仍存在单盘热点问题，不得不降低副本数和存储周期。此外，系统还存在缓存与 IO 未隔离、单盘单机存储热点、元数据过多导致 Rebalance 压力大、负载均衡复杂以及扩缩容困难等问题。这些痛点使得运维团队需要投入大量人力进行监控和干预，严重影响了集群的稳定性和资源利用率。

技术选型理由

在全面评估后，滴滴大数据团队选择 Apache Pulsar 作为新一代消息系统。Pulsar 的存算分离架构通过 BookKeeper 实现顺序刷盘，彻底解决了随机写入导致的 IO 瓶颈问题；其多级缓存机制（包括 Broker 堆外缓存和 Bookie 读写缓存）有效实现了 IO 隔离，避免了读写相互影响；Bundle 机制将海量分区映射到有限哈希环上，大幅降低了元数据管理和 Rebalance 压力；节点对等和无状态设计使得扩缩容变得简单高效，支持高峰期和故障期间的快速扩容。这些特性使 Pulsar 成为解决滴滴大数据运维痛点的理想选择。

业务实践与优化

在落地实践中，团队重点优化了以下几个方面。硬件选型采用 SATA HDD 盘 + NVME 的异构机型，NVME 作为 journal 和 index 存储介质，在降低成本的同时延长了存储周期并增加了副本数。通过利用 Pulsar 的 Ensemble 机制，实现数据自动均衡分布，集群中所有数据盘的存储容量利用率差异控制在 10% 以内，彻底解决了存储热点问题。运维方面，借助 Bundle 机制实现一键式负载均衡，热点 Broker 上的 bundle 可快速卸载并自动分配到最优节点，大幅提升了运维效率。

在扩缩容方面，Pulsar 展现出显著优势。计算层 Broker 扩容后可通过 bundle 漂移立即分担负载；存储层 Bookie 扩容后无需数据迁移，新数据自动选择低负载节点写入，实现了新老节点的 "双向奔赴"。故障恢复能力也得到极大增强，计算层无状态设计支持快速故障转移，存储层通过 readonly 模式和快速扩容确保服务连续性。这些改进使得滴滴大数据平台能够应对各种突发状况，保障数据通道的稳定运行。

目前，Pulsar 集群已在滴滴大数据平台稳定运行两年多，成功支撑了 Log->ES、BamaiLog->ES、BamaiLog->CK 和 Log->HDFS 等重要数据同步链路。相比原有的 DKafka 系统，Pulsar 在性能、成本和可靠性方面都带来了显著提升，为滴滴大数据业务的发展提供了坚实的技术保障。