Apache Pulsar 在小红书线上场景的探索与实践

本文整理自 Steven Lu、Linlin Duan 与 Xiangying Meng 在 Community Over Code Asia 2025 上的主题演讲。一起来看 Pulsar 在小红书的落地实践！

关于团队

团队的核心职责是负责小红书在线消息队列服务，专注于构建稳定可靠的基础组件（用于在线业务场景）。

小红书 MQ 架构

架构设计整体分为三个层次：运维控制层负责集群管理和监控；SDK+Proxy 层提供统一的接入接口；MQ 引擎层是核心的消息处理引擎。

其中包含几处关键设计：

数据流与管控流的分离，通过 discovery 服务进行统一管理。
多协议支持，提供两套客户端接口，分别是通用简化接口和流式化接口。
集群感知能力，通过 discovery 服务动态下发集群变更，使客户端能够感知到多活切换等操作。

这一架构经历了从原始的直接连接架构到当前架构的演进。目前，新架构已成功接入 50% 的在线业务流量，最终目标是实现 Pulsar 引擎的 100% 全量接入。

在架构的具体实践中，针对不同业务场景，主要分为两种模式：

面向高级用户的多活链路。该场景的特点是要求分钟级快速恢复，且业务本身对消息队列的依赖相对较弱。实现方式是采用双集群热备模式，数据完全对等写入和消费，并配备了消费者独立保护机制。
面向普通用户的单活逃逸方案。该场景的恢复时间目标在半小时级，业务对消息队列的依赖较强。实现方式是基于 Pulsar 的全局特性实现数据同步，通过消费位点同步机制，在故障时进行全量数据拉取，并保障最小的消费延迟。

支撑这些实践的是一套完善的容灾切换机制。切换场景主要分为两类：当单数据中心出现异常时，直接触发上层切换；当用户服务健康但消息队列本身出现异常时，则通过 discovery 服务自动完成切换。实现要点包括数据节点的自动发现、消费位点的精确同步，最终目标是实现客户端的无感知切换。保障措施涵盖生产端的快速切换、消费端的全量数据获取，以及最小消费延迟的保障。

挑战和收益

在迁移至新架构的过程中，遇到了几个主要的挑战：

首先是接入方式混乱。由于业务方使用了多种多样的客户端接入系统，导致了极高的维护成本。解决方案是通过将接入方式统一到 ddmq 架构，使用 UNIFIED_CLIENT 进行标准化接入。平滑迁移的关键是在 proxy 层实现切换控制，支持用户平滑迁移和故障时的快速回滚。

其次是资源利用率非常低的问题。旧的 RocketMQ 主从架构中，主节点负责实时读写和数据同步，而从节点几乎不承担请求，造成了大量"低效节点"，导致集群整体资源利用率低下。解决方案是迁移到支持快速扩缩容的新架构（Pulsar），从而提高资源水位利用率。

第三是数据冷却问题。旧架构为了追求极致的 IOPS，将所有数据全局写入文件，使得小流量 Topic 的数据分布非常离散。当出现冷读取时，会产生严重的随机 I/O 和 PageCache 污染。一个具体的故障案例是，某业务方启动了长期未使用的消费服务，导致集群云盘带宽被打满，进而使集群不可用长达 15 分钟。

尽管挑战重重，但迁移也带来了显著的收益。在资源优化方面，采用支持快速扩缩容的新架构，避免了低效的从节点，提高了资源利用率。在存储方面，实施了高性能硬盘与低性能硬盘的组合方案：数据先写入高性能盘并立即返回，在后台整理后再存入低性能盘。由于 PL1 和 PL0 云盘价格存在 2.85 倍的差异，这一改进使得集群机器成本降低了 46%。同时，新的存储方案使小流量 Topic 的数据存储更集中，有效减少了随机读取和 PCK 污染问题。

关于架构中的 Proxy 层价值，其优势在于能够避免用户代码改造，未来如果需要更换底层引擎，只需服务端升级即可。但其劣势在于增加了维护成本，并且需要重新实现分块消息等协议功能。这对于缺乏活跃开源社区支持的团队而言，维护 Proxy 层可能成为一个显著的挑战。

延迟消息

延迟消息是指生产者发送消息后，消费者需要在指定的延迟时间之后才能接收到的消息，典型场景包括电商订单超时取消和会议提醒等。

行业主流方案各有特点。RocketMQ 4.x 仅支持固定时间间隔，实现简单但场景受限。RocketMQ 5.x 基于时间轮实现了任意秒级精度，但其缺点是延迟时间若超过时间轮长度，会导致写放大问题。Pulsar 的原生方案支持任意精度的秒级延迟，但问题在于实时消息和延迟消息混合存储，长的延迟需求会迫使全量数据保存时间相应延长。

基于以上研究，我们自研了一套延迟消息方案。设计目标是支持任意精度的秒级延迟、支持月级的长延迟（以满足如物流签收等场景），且在实现上不与某个 MQ 进行绑定，能够兼容 RocketMQ、Pulsar 和 Kafka。

架构设计上，数据流路径是：业务消息首先经过 Proxy，然后被投递到一个内部 Topic，接着存入 Log DB，最后定时扫描到期消息并投递到目标 Topic。核心机制是借助 Log DB 按时间排序存储消息，并通过定时扫描来投递到期消息。在索引方面进行了优化，支持按 Topic 维度并行处理到期消息。

部署方案采用主从模型以实现高可用，通过多分片设计支持水平扩展。系统原生支持 K8s，便于扩缩容，并采用 SSD 存储来提升 Log DB 的读写性能。

总结与展望

小红书的实践可以总结为几个关键维度：

架构方面，成功从传统方案迁移至以Pulsar为核心的现代架构，实现了客户端统一接入、数据与管控分离，其难点在于兼容历史客户端API和消费位点的精确转换。

多活方案方面，根据业务等级提供了资源消耗大但切换快的双活架构，以及成本更低但存在服务中断窗口的单活逃逸方案。

延迟消息方面，其自研的系统通过独立存储引擎，在支持任意精度和超长延迟方面对比行业方案展现出明显优势。

存储方面，分层存储方案通过高低性能盘组合与数据归类整理，在降低成本 46% 的同时，有效解决了冷读性能问题。

目前，团队已成功迁移约 50% 的 RocketMQ 流量，未来的规划将聚焦于完成 100% 的全量 Pulsar 迁移，并持续优化弹性扩缩容、分层存储等高级功能，致力于进一步提升资源利用率和降低运营成本，为小红书的在线业务提供更加坚实、高效的基础设施保障。