本文结合消息队列进行选型介绍，就 Pulsar 和 RocketMQ 的特性作对比，介绍 Pulsar 在小红书在线消息队列的场景下如何落地，以及企业可以获得哪些实际收益。同时，文章结合小红书消息队列的实际情况、经验进行了整理和数据汇总。
分享概要
一、背景
1、消息队列的定义
2、行业趋势
二、现状分析
1、现状及规模
2、存在问题
三、演进路线
1、选型决策 Pulsar 或 RocketMQ5.x
2、演进方向
3、客户端标准化
4、架构升级到Pulsar
四、在线消息规划设计
五、总结与展望
1、阶段性进展和收益
2、展望
一、背景
1、消息队列的定义
消息队列（简称：MQ）是分布式架构中的重要组件，提供异步通信的基础能力，通过应用解耦降低系统复杂度，提升系统可用性和可扩展性。
消息队列核心组成：
Producer：生产者，负责产生和发送消息到 Broker；Consumer：消费者，负责从 Broker 中获取消息，并进行相应处理；Queue：保存消息的数据结构，提供消息队列先进先出特性；Message：实际数据内容，包含了生产者发送给消费者的信息；Broker：消息引擎，负责消息存储、确认、重试等。消息队列是不同应用之间异步通信的中间产品，其本质特征：
解耦：解除上、下游系统的依赖，达到解耦目的；削峰：通过使用消息队列作为缓冲，将多余的请求存放在队列中，避免系统因瞬时高并发请求而崩溃。当系统处理能力恢复时，再从队列中取出请求进行处理；异步：解耦合+转存，消息的处理结果不需要被即时依赖，上、下游系统可以异步进行，而异步本身直接带来了缓冲、削峰、最终一致性等能力。2、行业趋势
行业公司消息队列选型：
业界选型上，Kafka 是离线大数据重要组成，在线消息因为丰富的业务功能诉求（事务消息、延迟消息、死信消息等）选择 RocketMQ 或 Pulsar。
二、现状分析
1、现状及规模
Red Events MQ 基于 DDMQ 在小红书落地的一套 Discovery + Proxy + RocketMQ 引擎的架构，其架构如下：
当前形态：
管控平台：Topic 在管控平台创建和维护；服务发现：服务发现同步管控平台信息，对 SDK 提供元数据信息（集群信息）；Proxy：屏蔽用户对底层MQ的依赖，提供数据服务；Client SDK：客户端，由于客户端场景覆盖不足，导致各类客户端、各种连接方式共存，数据平台类的接入均覆盖不到。2、存在问题
三、演进路线
1、选型决策：Pulsar 或 RocketMQ5.x
RocketMQ 和 Pulsar 都是 Apache 的顶级项目，同样优秀；但是如下几点还是让我们决策 Pulsar 成为未来我们新的架构引擎：
Pulsar 独有的优势：
汇总成本收益：当前流量情况下，成本降低 48%；在未来 10 倍增长量的情况下，成本会持续降低。
在小红书当前场景，当前集群和流量规模情况下（RocketMQ 采用了 2 副本、承载同等流量的情况），如果使用 Pulsar 能带来如下收益：
1）存储成本下降：存储成本更低，Pulsar 多盘部署架构，部署架构实现让存储成本下降 27%.
RocketMQ 2 副本和 Pulsar 3 副本消耗资源都是：32核+128GB内存+16TB磁盘，但是 Pulsar 可以借助多盘特性、用更廉价的盘拼出更高的性能：基于新架构，设计更合理的部署架构，拿到的收益.[前提] CPU、内存、存储容量保持不变的前提，拿到了其他的收益；
[收益] 磁盘总带宽上升：经过多盘的拼接，磁盘带宽从350MB/s上升600MB/s，提升71%；
[收益] 成本下降：从现有架构的 RocketMQ2 副本（Master/Slave Broker）到 Pulsar3 副本（1*Broker+3*BookKeeper），成本下降27%.
2）CPU利用率提升：提升资源利用率，通过实现副本流量对等，有效规避RocketMQ Slave 副本资源浪费的情况，可降低 21.5% 的 CPU 资源成本。
追赶读（Catch-up Reads）：消费者落后，在线业务场景很少，RocketMQ 的 Master/Slave 都会承载流量，线上追赶读的峰值流量：流量占比：3.5%；追尾读（Tailing Reads）：写完立刻读，在线业务此场景偏多，RocketMQ此架构只有 Master 才会承载，线上追尾读的峰值流量：流量占比：96.5%，此场景下存在 CPU 的资源浪费：Master 节点：16 核 CPU 峰值使用率高达 50%，计算资源主要消耗在 Client数据的写、读、Slave 的同步；
Slave 节点：16 核 CPU 峰值使用率只有 7%，计算资源主要消耗在从 Master 拉取数据；
按 RocketMQ 的 Master 节点的 CPU 使用率 50% 满足集群扩容需求，但是 Slave 节点的 CPU 利用率确很低，Pulsar 可实现副本完全对等，如果换成 Pulsar，可提升这 43% 的 CPU 使用率，在缩容降本情况下，可降低 21.5% 的成本。3）弹性伸缩、按量计费：基于这个特性， 让成本降低30%
核心逻辑：配额：为了满足指定指定 TPS 需要提供的资源，当前集群评估水位的标准是峰值 TPS；
实际使用量：用户实际使用的资源，用平均 TPS 代替；
冗余率：（配额 - 实际使用量) / 配额，得到资源冗余率，这部分冗余资源就是弹性伸缩架构理论上可以获得的最大收益；
小红书在线消息现状，弹性伸缩可得最大收益：按 2 小时调度一次，可节约 30% 左右的资源用量。4）运维友好：云化部署、弹性伸缩更加平滑。
云化部署：借助 Ones/K8s 云部署优势，减少重复的运维能力建设；扩容平滑：无需做扩容分区、迁移分区等运维操作；计算层（Broker 无状态）：扩容后，无需运维，流量自动均衡；
存储层（BookKeeper 有状态）：扩容后，无需要干预，新 Ledger 创建后，流量自动覆盖新节点；
缩容平滑：做到无损，不改变顺序读写，更加优雅；计算层（Broker 无状态）：缩容后，自动卸载流量，流量自动均衡到其他节点；
存储层（BookKeeper 有状态）：缩容后，无需要干预，流量自动均衡（策略有：非紧急的缩容，节点直接隔离待数据失效+紧急下线数据迁移）。
Pulsar VS RocketMQ 5.0核心能力（绿色块：代表优势；橘色块：代表劣势）
Pulsar 架构图
RocketMQ 5.0 架构图
2、演进方向
核心名词解释：
设计思想：Red Events（事件总线）本质上是一个 MQ 代理，目的是对用户屏蔽底层 MQ 的实现，提供统一的接入方式、集群的运维和治理；Topic：是数据发布和订阅的基本单位，它代表了相同类型的消息流；Event：是对 Topic 的抽象，提供了集群和 Topic 的绑定关系，可动态调整，更便于用户使用；元数据：Topic 的元数据服务，供 Events Client 感知集群等信息；Events Client：标准化的客户端，提供统一的接入方式，用户发送、消费消息的工具；Proxy：MQ 代理，提供统一的集群运维和治理；Pulsar Clusters：MQ 的引擎，一套存算分离的云原生架构。设计目标：
Events 客户端标准化、可观测、功能轻量：作为统一接入的客户端，各类语言（http兜底）客户端、各类场景（flink等）全量覆盖，让用户接入 MQ 更加稳定、可控Events Proxy：MQ 的代理，屏蔽用户对底层 MQ 引擎选择，只需要关注核心问题：RT/吞吐/功能/成本MQ 新引擎的方向：替换原有的 RocketMQ4.x，构建一套存算分离的云原生架构，新引擎做到 100% 流量全部覆盖通过客户端标准化和平滑迁移这两种手段，让 Pulsar 在小红书落地成为可能。
3、客户端标准化
客户端标准化让客户端接入都收敛，实现标准化接入：
用户客户端改造，使用标准化接入方式 EventClient；客户端改造过程中触发自动化灰度切流；客户端改造完成，观察业务指标是否符合预期。及时发现并解决客户端改造过程中的问题。4、架构升级到Pulsar
Pulsar 迁移路径：
按优迁移、平滑无感：按业务优先级，从低优到高优逐步迁移，旨在平滑迁移，用户无感；Pulsar 迁移最终覆盖到100%：依赖客户端标准化的推动进度，首先推动 11% 上下游均标准化的部分，之后随标准化桥接推进，共同推进到 71%，最终实现Pulsar 100% 的覆盖；迁移同时对资源使用率的治理：Pulsar 迁移过程也将逐步实现资源使用率的提升，从观察期 30%，最终提升资源使用率到 50%.四、在线消息规划设计
整体架构设计点：
以 Pulsar 为底座，构建一个存算分离的云原生架构；构建更多特色功能：跨云多活、实时队列、延迟队列、分层存储能力、弹性伸缩及弹性计费的功能，分阶段让用户享受到架构的红利。
整个架构的设计维度：
创建 Topic 入口统一：所有 Topic /消费组都在管控平台创建；Client 所有场景覆盖：Events 客户端标准化、可观测、功能轻量：各类语言（http兜底）客户端、各类场景（flink等）全量覆盖；Events 客户端标准化、可观测、功能轻量：操作均通过 Events Proxy 做数据通信；Events Proxy：MQ 的代理，屏蔽用户对底层 MQ 引擎选择，只需要关注核心问题：RT/吞吐/功能/成本；MQ 全链路能力对齐：支持云原生，容器化、弹性扩缩、具备弹性计费能力（按量计费）、支持各维度多活。五、总结与展望
1、阶段性总结
演进计划当前进度：
新架构（Pulsar）流量占比11.8%.当前已经拿到的收益：
成本：降低42%（主要是存储成本下降，使用了同容量、多块更廉价的盘）；资源利用率（CPU使用率）：34%（主62%、从7%）提升到60%；RT耗时（客户端E2E ）：max(P99) 20.2ms 降到 5.7ms；人工运维量：当前都部署在云上，借助云调度+自动卸载+注册，降低运维工作。2、展望
长远规划：完成 Pulsar 规划，制定客户端标准化、平滑迁移计划，同时做到稳定性建设。
1）Pulsar 落地：
继续完善功能完备性、生产稳定性、可观测 、运维能力；按照集群重保等级逐一迁移到 Pulsar；新Topic收口：新申请 Topic 直接创建在 Pulsar；100% 平滑迁移到 Pulsar，下线 RocketMQ.2）客户端标准化推进：
通过直接客户端改造和间接标准化（框架底层代码桥接，间接实现标准化）两种方式共同推进客户段标准化的覆盖；同时也逐步扩大 Pulsar 迁移范围；最终实现客户端标准化的 100% 覆盖。3）稳定性建设：
快速止损预案应对（共同的目标）：去应对未知场景的 Bug，快速止损，这不仅是未来引擎，也是当前引擎所要具备的能力；Monitor 全链路探针：端到端的探针，核心链路全覆盖，及时发现故障节点。>>>>参考资料
Apache Pulsar™ documentation：https://pulsar.apache.org/docs/Apache RocketMQ documentation：https://rocketmq.apache.org/docs/Pulsar Meetup 北京 2024：https://mp.weixin.qq.com/s/kj6nf_iMc7r8rzc5XXRdUg作者介绍
诺林，在线消息队列方向负责人，开源社区角色：Apache BookKeeper Committer
无桀，在线消息队列研发，开源社区角色：Apache Pulsar Contributer
月初，在线消息队列研发，开源社区角色：Apache Pulsar Committer
来源丨公众号：小红书技术REDtech（ID：gh_f510929429e3）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
活动推荐
为了和大家一起探索AI相关技术在大数据、数据资产管理、数据库、运维等领域的最佳落地方式，挖掘由此激发的软件发展和技术进步，第九届DAMS中国数据智能管理峰会将于2024年11月29日在上海举办，携手一众产学研界技术领跑单位，带来新思路、重实践、可落地的全日干货盛宴。
活动详情：
