解析云原生消息流系统 Apache Pulsar 能力及场景

导语

Apache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性，被看作是云原生时代实时消息流传输、计算和存储最佳解决方案。

Apache Pulsar 属于分布式消息流领域，为什么它是云原生时代最佳解决方案，它到底能解决什么问题？

业务背景

队列场景——解耦

相信大家对 MQ（Message Queue） 这个名词并不陌生。简单来说，MQ 是用于存放消息的队列，是一种先进先出的数据结构。很多编程语言都自带了这类内存队列，作为多任务之间的数据通道进行异步解耦，例如 Java 的 java.util.Queue 。

以实际生活中的网上购物为例，李四购买了张三的商品，张三需要把物品送到李四手上，张三通过快递服务把物品送到指定地址，快递服务会将物品放在离李四最近的快递仓库中，然后通知给李四来收取。张三也可以直接把物品送给李四，但是需要双方约定好时间和地点，存在上下游强依赖问题，快递服务通过中间的快递仓库解决了强依赖问题。只需通知李四物品到达仓库的时间和地点，李四可以按照自己的时间来收取，这样不仅解耦了上下游的依赖，同时也提升各自的处理效率。

在实际业务流程中也大量存在这样的场景，上游将数据写入到消息队列进行暂存，通知下游来消息队列获取数据消费，完成整个业务流程处理。例如，一个互联网购买业务流程可能需要调用多个服务，包含下单服务、支付服务、发货服务等。如果需要等待这些服务都处理完才能结束业务流程，则用户一次操作时长可能到达秒级或者更长，并且大部分操作可以异步处理，一些非关键的业务（如通知服务）不应该影响或阻塞主流程。

上图是一个典型的电商业务处理流程。利用消息队列可以将支付服务、发货服务以及后续的积分服务等进行解耦，在支付完成时即可结束用户本次操作，后续通过异步的方式把接下来的流程完成。在此场景中，对消息队列最基本的要求是性能、延迟与持久化等能力，例如快递服务同时能运输多少物品、多久能达指定地点，以及快递仓库能存储多少物品，这些直接决定了快递服务质量。

流场景——高吞吐

随着大数据时代的到来，数据对于企业来说越来越重要，需要一套平台把海量数据收集和整合并充分利用。在这个处理流程中，消息队列承担着重要的角色，例如作为统一数据上报的入口，这些数据包括应用程序的消息、服务级的日志流水以及数据库中的业务数据等，因此消息队列包含了完整业务流程数据，为下游的实时数仓以及离线数仓提供数据原材料，以及目前非常火爆的流式计算，通常利用 Flink、Spark Streamming 等计算平台与消息队列结合进行实时计算。

相比队列场景，在流场景中，消息系统需要具备更高的吞吐以及顺序消费等能力。

那么现代业务和基础设施要求消息系统应该具备哪些能力？

消息系统应具备的能力

核心能力

选择分布式中间件，首先需要考虑高可靠、高一致、高可用、高性能这些核心能力。

• 高可靠： 在队列场景中，大部分业务对数据的可靠性要求非常高，例如不允许交易数据丢失，这就要求一份数据需要存储多个副本。最好副本存在不同的位置，降低同时损坏的风险。
• 高一致： 多副本提升了数据的可靠性，同时也带来多副本数据不一致的难题，不能出现在副本 A 读出来的用户金额为 10 元，而在副本 B 读出来的用户金额为 20 元的问题。分布式一致性算法专门解决这类问题，例如主流的 Raft 协议。
• 高可用： 在线业务场景中，消息队列已成为关键路径，服务的可用性非常重要。然而在一个分布式系统中节点故障是常态，需允许部分节点异常或者宕机，并且具备故障转移、自动修复等能力，且业务基本无感知。
• 高性能： 即系统具备高性能或者高吞吐能力来满足大流量的场景。
  

目前的消息系统很难同时满足以上四高要求，这也是分布式系统一大难题，一般根据业务特性取一个折中的方式。例如传统的 RabbitMQ 保证了高可靠、高一致、高可用，但满足不了高性能场景；Kafka 保证了高性能、高可用，但是满足不了高可靠、高一致的金融场景，即使可以通过配置勉强应用，但是整个性能和延迟断崖式下降，参考性能测试报告。

基础能力

消息系统最基础的能力是提供发布订阅的服务，根据业务场景的不同会有不同的诉求。

$ | 队列场景（线上业务）

1. 消费模式： 在线上业务场景中，通常逻辑处理比较耗时，允许多个消费者来协同处理。业务服务的部署不应该受限消息队列的限制，能够灵活扩缩容。

2. 异常处理： 消费端崩溃后，支持恢复后接着上次的偏移量继续消费。业务逻辑处理失败后，支持该条消息再次消费，例如失败消息放入重试队列中，达到最大重试阀值后，再进入死信队列，最大程度保证消息处理成功。

3. 延迟/定时消息： 在很多业务场景中并不希望消息立马被消费掉，例如连续包月场景，用户在第一次签订了扣款协议后可以生产一条下次扣款的延迟消息，通过消息队列来触发扣款流程。

4. 事务消息： 多个生产和消费操作具备事务能力。

$ | 流场景（大数据业务）

1. 顺序消息： 在流场景中很多情况下需要保证消息的顺序性，无论是生产端还是消费端，例如在 CDC 场景中将数据库的 binlog 同步到消息队列中。

2. 消息回溯： 消息持久化后，允许对同一份数据多次消费，此能力非常有价值。它不仅可以让其它消费组共享一份数据，也可以重置偏移量对历史数据进行再次消费，例如在逻辑变更后，需要重新统计计算。

3. 海量积压： 如果出现生产端和消费端速率不匹配，或者消费端异常会产生消息积压现象，这是非常常见的现象，消息系统应具备海量积压的能力。

在队列场景和流场景中，其实还有很多交叉能力，例如顺序消息、海量积压也存在于队列场景，这里只是为了对比将其区分开来。

运营能力

完善的运营能力对于消息系统落地也非常重要，包含几个层面：

• 控制能力：运维人员非常关心消息系统能做到什么粒度的控制。从资源角度来说，消息系统应该具备多租户以及资源隔离能力，以及 Topic 级别流量控制能力来满足企业级消息总线的基本资源控制要求。从安全角度来说，消息系统需具备常用的身份认证方式和 Topic 级别权限控制，以及消息体加密能力来满足企业安全要求。

• 查询能力：消息系统的关键信息能够开放 API，例如 Topic 基础信息、生产消费流量指标、消息积压情况等，以及消息轨迹能力来方便运维人员快速排查问题。

• 监控能力：消息系统能够将监控指标暴露出来，包含生产消费相关的监控指标以及资源监控指标，便于接入到监控告警平台。

• 云原生能力：云原生能力主要体现在快速扩缩容、故障转移、自动恢复等方面。在不影响当前服务质量的前提下，降低运维人员操作难度，减少过多的手动操作。

生态能力

消息系统与周边生态对接的能力也是需要考虑。在队列场景中，更多的考虑是系统能否兼容更多的协议，例如 HTTP 协议、AMQP 协议、MQTT 协议等；在流场景中，更多的考虑是系统能否原生对接大数据生态，以及周边存储系统能否快速将数据同步到消息系统中，或者双向同步。

上面花了较大的篇幅介绍了消息系统的业务场景以及应该具备的能力，下面是 Apache Pulsar 的一个简单功能图，Pulsar 基本满足上述提到的能力，这里并不打算介绍 Pulsar 原理以及详细功能特点，可以进入 Apache Pulsar 官网[1] 了解详情。接下来我们看看新一代分布式消息队列 Apache Pulsar 能够解决哪些场景。

Apache Pulsar 能解决的场景

统一队列和流场景

目前大部分企业中都存在两套消息系统，一个是用于在线业务场景的 RabbitMQ 或者 RokcetMQ，另一个是用于大数据日志场景的 Kafka。其根本原因是这些系统不能同时满足两种场景。这对企业来说，无论是学习成或者运维成本，还是资源成本都会增加。

Apache Pulsar 能够将这两个场景进行统一，其核心存储层 Apache BookKeeper 为 Pulsar 提供了企业级稳定的 I/O 质量，具备高性能、强一致性、读写隔离、灵活 SLA 等特性，这里有详细的性能测试报告。其计算存储分离架构和分片存储模式能够解决 Kafka 系统中所面临的痛点，例如扩容带来的数据再平衡以及海量 Topic 等问题。有了存储层的基础，服务层统一相对容易。Pulsar 原生提供了多租户能力，统一的消费模型可以满足不同场景的要求。

腾讯计费（Midas）是一个典型的案例，腾讯计费基于 Pulsar 构建了日百亿级规模的消息总线，覆盖了核心交易流程、实时对账、实时监控等业务。

实时数仓场景

随着对数据的实时性要求越来越高，很多企业都在构建实时数仓，例如一款新产品上线，运营人员需要根据实时效果数据来及时调整运营策略，以及在大屏数据实时展示中，需要实时展示时刻变化的数据。Apache Pulsar 适合作为实时数据收集的入口，并提供了丰富的 Pulsar Source 工具将周边的存储数据接入进来。同时 Pulsar 抽象了协议层，提供多种协议接入，例如 Kafka 协议、AMQP 协议等。Pulsar 基于 Topic 级别的 Schema 管理结合 Pulsar Flink Connector 可以非常方便地进行实时流计算。

另外 Apache Pulsar 还有一个非常好的特性，即允许将历史数据卸载到更低廉的存储系统中，比如 HDFS、S3 等，并且与存储在 BookKeeper 中的实时数据形成统一的存储视图，对外提供统一的 API，结合 Flink 实现批流融合计算、构建实时数仓。

BIGO 是一个典型的案例，BIGO 团队基于 Pulsar 和 Flink 构建了日千亿级规模的实时数仓，覆盖了实时指标计算、模型训练、ABTest 实时验证等业务。

在大数据业务场景中，实时数仓和离线数仓可能共存，比如在基于 HIVE 的数据分析场景中，离线数仓中使用最频繁。从上面的模式来看，目前还无法将实时数仓和离线数仓的数据进行统一存储。Apache Pulsar 目前正在对接数据湖生态，通过层级存储将 Pulsar Topic 历史数据以数据湖的格式存储，这样基于数据湖的生态可以更好地与原有的大数据生态进行结合，用户可根据实际需求灵活选择。

IoT 场景

据 IoT Analytics 报告，2020 年全球物联网连接数达到 117 亿，预计 2025 年将达到 309 亿，面对 IoT 场景或者边缘计算场景，高质量的数据管道是一个关键服务，需具备海量设备接入、高性能低延迟、顺序消费等能力。Apache Pulsar 正好都能满足这些要求，比如 MQTT on Pulsar (MoP)，海量 Topic 以及多种消费模式满足顺序消费场景。

除此之外，Pulsar Functions 非常适合边缘计算中的数据处理层场景，例如 Actor Cloud 利用 Pulsar Functions 实现了数据处理规则管理引擎。

其它场景

Apache Pulsar 还有很多实用的功能，例如跨地域复制能力能够提供在线业务场景下集群级别灾备，满足金融级别的可用性和可靠性以及大数据场景下多地域数据汇聚场景；Pulsar Functions 提供轻量级数据路由和转换能力，满足简单的 ETL 场景等。

总结

一切技术的诞生都是为了解决实际问题，Apache Pulsar 的诞生弥补了同类消息系统很多不足的地方，同时它也是第一个实现计算存储分离架构的消息系统，如果您正在对消息系统进行方案选型，Apache Pulsar 是一个不错的选择。

• 引用链接
  [1] Apache Pulsar 官网: https://pulsar.apache.org/

关于作者
刘德志，Apache Pulsar Committer，StreamNative 解决方案专家，前腾讯计费平台技术专家。曾任职腾讯，负责腾讯计费平台架构与技术方案实施，并主导了腾讯云 TDMQ for Pulsar 产品落地实施，拥有丰富的消息中间件开发与运维经验。活跃于最新一代云原生消息中间件开源项目 Apache Pulsar 社区，对消息和流系统拥有独特的洞察与思考、以及丰富的行业实践沉淀。