---

Pulsar Developer Day 2025 将于 12月6日（本周六）下午在北京举办，与来自小红书、中原银行、360、中电金信、谙流科技、StreamNative 等企业的多位社区技术大咖相聚北京，分享 Pulsar 在不同行业的应用实践，共话元数据管理、金融级可靠性、Serverless 成本优化、跨协议兼容、延迟消息等技术实践。

报名链接：https://www.huodongxing.com/event/3836168737400

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

关于团队

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

小红书 MQ 架构

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

其中包含几处关键设计：

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

架构演进

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

业务场景实践

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

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

容灾切换机制

支撑这些实践的是一套完善的容灾切换机制。切换场景主要分为两类：

1. 数据中心异常：当单数据中心出现异常时，直接触发上层切换
2. 消息队列异常：当用户服务健康但消息队列本身出现异常时，则通过 discovery 服务自动完成切换

实现要点包括数据节点的自动发现、消费位点的精确同步，最终目标是实现客户端的无感知切换。保障措施涵盖生产端的快速切换、消费端的全量数据获取，以及最小消费延迟的保障。

挑战和收益

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

1. 接入方式混乱

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

2. 资源利用率低

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

3. 数据冷却问题

旧架构为了追求极致的 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 的读写性能

总结与展望

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

1. 架构演进

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

2. 多活方案

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

3. 延迟消息

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

4. 存储优化

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

未来规划

目前，团队已成功迁移约 50% 的 RocketMQ 流量，未来的规划将聚焦于：

• 完成 100% 的全量 Pulsar 迁移
• 持续优化弹性扩缩容、分层存储等高级功能
• 进一步提升资源利用率和降低运营成本
• 为小红书的在线业务提供更加坚实、高效的基础设施保障

---

Apache Pulsar 作为一个高性能、分布式的发布-订阅消息系统，正在全球范围内获得越来越多的关注和应用。如果你对分布式系统、消息队列或流处理感兴趣，欢迎加入我们！

Github: https://github.com/apache/pulsar