小红书在线场景Pulsar技术实践

分享内容

本次分享结合消息队列进行选型介绍，就 Pulsar 和 RocketMQ 的特性作对比，介绍 Pulsar 在小红书在线消息队列的场景下如何落地，以及企业可以获得哪些实际收益。同时，结合小红书消息队列的实际情况、经验进行了整理和数据汇总。

01 背景

1.1 消息队列的定义

消息队列（简称：MQ）是分布式架构中的重要组件，提供异步通信的基础能力，通过应用解耦降低系统复杂度，提升系统可用性和可扩展性。

消息队列核心组成：

• Producer：生产者，负责产生和发送消息到 Broker；
• Consumer：消费者，负责从 Broker 中获取消息，并进行相应处理；
• Queue：保存消息的数据结构，提供消息队列先进先出特性；
• Message：实际数据内容，包含了生产者发送给消费者的信息；
• Broker：消息引擎，负责消息存储、确认、重试等。

消息队列是不同应用之间异步通信的中间产品，其本质特征：

• 解耦：解除上、下游系统的依赖，达到解耦目的；
• 削峰：通过使用消息队列作为缓冲，将多余的请求存放在队列中，避免系统因瞬时高并发请求而崩溃。当系统处理能力恢复时，再从队列中取出请求进行处理；
• 异步：解耦合 + 转存，消息的处理结果不需要被即时依赖，上、下游系统可以异步进行，而异步本身直接带来了缓冲、削峰、最终一致性等能力。

1.2 行业趋势

行业公司消息队列选型：

业界选型上，Kafka 是离线大数据重要组成，在线消息因为丰富的业务功能诉求（事务消息、延迟消息、死信消息等）选择 RocketMQ 或 Pulsar。

02 现状分析

2.1 现状及规模

Red Events MQ 基于 DDMQ 在小红书落地的一套 Discovery + Proxy + RocketMQ 引擎的架构，其架构如下：

当前形态：

1. 管控平台：Topic 在管控平台创建和维护；
2. 服务发现：服务发现同步管控平台信息，对 SDK 提供元数据信息（集群信息）；
3. Proxy：屏蔽用户对底层 MQ 的依赖，提供数据服务；
4. Client SDK：客户端，由于客户端场景覆盖不足，导致各类客户端、各种连接方式共存，数据平台类的接入均覆盖不到。

2.2 存在问题

03 演进路线

3.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 副本（1Broker+3BookKeeper），成本下降 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% 的成本。