本文转自腾讯云中间件，作者张超，腾讯数据平台部 MQ 团队高级工程师，Apache TubeMQ(incubating) PMC，Kafka-on-Pulsar Maintainer，Apache Pulsar Contributor

腾讯数据平台数平 MQ 团队对 Pulsar 做了深刻调研以及大量的性能和稳定性方面优化，目前曾经在腾讯云音讯队列 TDMQ 落地上线。本文次要简略梳理了 Pulsar 反对的一些传统音讯队列利用场景，以及 Pulsar 新个性对更多场景的反对。

对于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。

GitHub 地址：http://github.com/apache/pulsar/

音讯队列概述

什么是音讯队列

音讯队列（Message Queue，简称 MQ），是指在音讯的传输中保留音讯的容器或服务，是一种异步的服务间通信形式，实用于无服务器和微服务架构，是分布式系统实现高性能、高可用、可伸缩等高级特效的重要组件。

常见的支流音讯队列有 ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ、Pulsar 等。而在公司内有 TubeMQ、Ckafka、TDMQ、CMQ、CDMQ、Hippo 等。

音讯队列特点

分布式

音讯队列都是分布式的，因而才能够提供异步、解耦等性能。

可靠性

基于音讯的通信是牢靠的，音讯不会失落。大多数音讯队列都提供将音讯长久化到磁盘的性能。

异步

通过音讯队列，可将近程同步调用拆解成为异步调用。对于不须要获取近程调用后果的利用场景来说，性能晋升显著。

松耦合

音讯间接由中间件存储和散发。音讯生产者只需关注如何将音讯发送给音讯中介服务器；消费者只需关注如何从中介服务器订阅。生产者和消费者之间是齐全解耦的，不须要晓得彼此的存在。

事件驱动

能够将简单的利用零碎重构成为事件驱动的零碎。事件溯源（Event Sourcing），示意一个对象从创立到沦亡，会通过的多种状态。如果把对象的状态变动都存储下来，岂但能够依据状态变动记录获取对象的以后状态，也能够回溯对象的变动过程。音讯队列能很好地反对这样的零碎设计形式，将触发对象状态变动的事件放入音讯队列。

音讯队列分类

在 JMS（JAVA Message Service）规范中，有 P2P（Point to Point）和 Publish/Subscribe(Pub/Sub) 两种音讯模型。

P2P

P2P 的特点是每个音讯只有一个消费者。音讯生产者将音讯发送到音讯队列（Queue）中，只有一个消费者可能生产此音讯，生产实现之后音讯即删除。任意一个消费者都能够生产这个音讯，但音讯相对不会被两个消费者反复生产。

Pub/Sub

Pub/Sub 的特点是公布到 Topic 的音讯会被所有订阅者生产。音讯生产者将音讯发送到音讯主题（Topic）中，所有订阅这个主题的消费者都能够生产此音讯，当所有订阅者都生产实现之后能力删除音讯。

音讯的生产者和消费者之间有工夫依赖，只有当时订阅这个主题的消费者才可生产。如果先发送音讯，后订阅主题，那么订阅之前的音讯将不能被这个订阅者生产。

传统企业型音讯队列 ActiveMQ 遵循了 JMS 标准，实现了点对点和公布订阅模型，但其余风行的音讯队列 RabbitMQ、Kafka 并没有遵循 JMS 标准。

而在 实时流式架构 中，音讯队列的消息传递能够分为 队列（Queue）和 流（Stream）两类。

队列（Queue）模型

队列模型次要是采纳无序或者共享的形式来生产音讯。通过队列模型，用户能够创立多个消费者从单个管道中接管音讯；当一条音讯从队列发送进去后，多个消费者中的只有一个（任何一个都有可能）接管和生产这条音讯。音讯零碎的具体实现决定了最终哪个消费者理论接管到音讯。

队列模型通常与无状态应用程序一起联合应用。无状态应用程序不关怀排序，但它们的确须要可能确认（ACK）或删除单条音讯，以及尽可能地扩大生产并行性的能力。典型的基于队列模型的音讯零碎包含 RabbitMQ 和 RocketMQ。

流式（Stream）模型

相比之下，流模型要求音讯的生产严格排序或独占音讯生产。对于一个管道，应用流式模型，始终只会有一个消费者应用和生产音讯。消费者依照音讯写入管道的确切程序接管从管道发送的音讯。

流模型通常与有状态应用程序相关联。有状态的应用程序更加关注音讯的程序及其状态。音讯的生产程序决定了有状态应用程序的状态。音讯的程序将影响利用程序处理逻辑的正确性。典型的基于流模型的音讯零碎包含 Kafka、TubeMQ。

传统音讯队列的利用场景

异步调用

假如有一个零碎调用链路为 A 调用 B 耗时 20ms，B 调用 C 耗时 20ms，而 C 调用 D 须要 2s，这样下来整个调用须要耗时 2040ms。但实际上 A 调用 B，B 调用 C 只须要 40ms，而 D 零碎的引入间接导致系统性能降落约 50 倍。此时咱们能够思考引入音讯队列，将 D 零碎的调用抽离进去，做一个异步调用：零碎 A 到零碎 B 再到零碎 C 后就间接完结，零碎 C 将音讯发送到音讯队列中，零碎 D 从音讯队列里取音讯进行生产，这样子咱们零碎的性能就进步了靠近 50 倍。

零碎解耦

各个业务零碎仅须要解决本人的业务逻辑，发送事件音讯到音讯队列。上游业务零碎间接订阅音讯队列的队列或主题获取事件。音讯队列可用于单体利用被拆解为微服务后不同微服务间的通信。零碎解耦的益处是不同零碎的迭代不再相互依赖，能无效缩短数据链路长度，进步数据处理效率。

削峰填谷

大型流动带来较高流量时，没有做好相应爱护容易导致系统超负荷甚至解体，而限度太过则会导致申请大量失败而影响用户体验。音讯队列服务领有高性能的音讯解决能力，能够承接流量脉冲而不被击垮，在确保零碎可用性的同时，通过疾速无效的申请响应技术晋升用户体验。其海量音讯沉积能力确保上游业务在平安水位内平滑稳固的运行，防止流量顶峰的冲击。

播送告诉

零碎一个状态的扭转，须要告诉多个相干零碎，可通过音讯订阅的形式推送给各个订阅者零碎。比方数据库值的扭转，须要告诉所有的缓存零碎更新，能够把数据库值扭转发送音讯给音讯队列，而后各缓存订阅相干主题，收到音讯后更新本人的缓存。

分布式缓存

在大数据场景中，日志剖析往往须要解决大量日志，不可能存储在一台物理机上。音讯队列可提供一个集群，用来存储海量音讯，将其缓存到音讯队列，进一步供实时剖析系统分析日志。Kafka 和 TubeMQ 在大数据处理中往往充当分布式缓存的作用。

音讯通信

音讯队列个别都内置了高效的通信机制，因而也能够用在纯的音讯通信。比方实现点对点音讯队列，或者聊天室等。

Pulsar 的利用场景

Pulsar 作为新一代存储计算拆散架构的音讯队列服务，不仅实用于下面提到的传统音讯队列的利用场景，它的一些新个性还为更多利用场景带来可能。

队列和流的交融—保护一套 MQ 服务就够了

Apache Pulsar 形象出了对立的 producer-topic-subscription-consumer 生产模型，既反对队列模型，也反对流模型。在 Pulsar 的音讯生产模型中，Topic 是用于发送音讯的通道。每一个 Topic 对应着 Apache BookKeeper 中的一个分布式日志。发布者公布的每条音讯只在 Topic 中存储一次；存储的过程中，BookKeeper 会将音讯复制存储在多个存储节点上；Topic 中的每条音讯，能够依据消费者的订阅需要，屡次被应用，每个订阅对应一个消费者组。只管音讯仅在主题（Topic）上存储一次，然而用户能够有不同的订阅形式来生产这些音讯：

• 消费者被组合在一起以生产音讯，每个生产组是一个订阅。
• 每个 Topic 能够有不同的生产组。
• 每组消费者都是对主题的一个订阅。
• 每组消费者能够领有本人不同的生产形式：独占（Exclusive），故障切换（Failover）或共享（Share）。

Pulsar 通过这种模型，将队列模型和流模型这两种模型联合在了一起，提供了对立的 API 接口。这种模型，既不会影响音讯零碎的性能，也不会带来额定的开销，同时还为用户提供了更多灵活性，不便用户程序以最匹配模式来应用音讯零碎。

多种 MQ 协定兼容—轻松迁徙传统 MQ 服务

在 Pulsar 架构中，为了解决 Bookie 存储音讯和避免音讯失落等，基于 Managed Leger 实现了一套分布式的流程封装。Pulsar Protocol Handler 解决 Pulsar 中生产者和消费者发送进去的 TCP 申请，将其转化为可读取状态的操作。Pulsar 2.5 版本后，将 Protocol Handler 接口独自脱离了进去，利用这个框架就能够独自实现自定义协定的转换，比方 Kafka、AMQP 等，能够帮忙存量的 MQ 业务轻松迁徙到 Pulsar。

Kafka Protocol Handler 目前是一个独立的我的项目在保护— Kafka On Pulsar（简称 KoP），因为公司内存量 Kafka 业务很多，数平 MQ 团队针对 KoP 做了大量的优化工作，腾讯当初有其余团队也在更深度参加 KoP 我的项目，详情能够参考腾讯加盟：Kafka-on-Pulsar 我的项目迎来 2 位腾讯 Maintainer！

企业级多租户个性—数据安全有保障

作为企业的音讯中枢，Apache Pulsar 自诞生之日起就反对多租户，因为该我的项目最后就是为了满足 Yahoo 的严格需要，而过后市面上没有任何可用的开源零碎可能提供多租户性能。在 Pulsar 的设计中，租户能够跨集群散布，每个租户都能够有独自的认证和受权机制；租户也是存储配额、音讯 TTL 和隔离策略的治理单元。Pulsar 通过下列形式满足了多租户场景下的数据安全：

• 通过为每个租户进行身份验证、受权和 ACL（访问控制列表）取得所需安全性。
• 为每个租户强制施行存储配额。
• 以策略的形式定义所有隔离机制，策略可在运行过程中更改，借此升高运维老本并简化管理工作。

跨地区复制—自带跨机房冗灾能力

在大型的分布式系统中，都会波及到跨多个数据中心的需要。在对服务质量和灾备要求更高的场景中，会布局将机房部署在地理位置扩散的多个数据中心内。在此类多数据中心部署中，通常会应用跨地区复制机制提供额定的冗余，以防某个数据中心故障、天然侵害或其余事件导致服务无奈失常运作。Apache Pulsar 在设计之初就退出了对 Yahoo 寰球十多个机房的跨地区复制的需要。Apache Pulsar 的跨地区多机房互备个性是 Pulsar 企业级个性的重要组成部分，它在保证数据稳固牢靠的同时，为用户提供了便捷的操作和治理。

在上图中，无论 Producer P1、P2 和 P3 在什么时候别离将音讯公布给 Cluster A、Cluster B 和 Cluster C 中的 Topic T1，这些音讯均会立即复制到整个集群。一旦实现复制，Consumer C1 和 C2 即可从本人所在的集群生产这些音讯。

Pulsar 的跨地区复制不仅利用在跨数据中心数据备份的场景，在 PowerFL 联邦学习平台中跨地区复制的能力还被用来做通信服务应用。

云原生反对—助力服务上云

云原生的原生即软件设计之初就思考到了未来会被运行在云端的可能，从而在设计层面上就充分利用了云资源的特点，典型的是分布式和弹性伸缩的能力。Pulsar 之所以说是云原生的音讯平台，外围就是它的架构设计可能充分利用分布式的、可能弹性伸缩的云端资源。以 Pulsar on Kubernetes 为例，Bookie 是有状态的节点，然而节点之间是对等的，能够采纳 StatefulSet 来部署；而 Broker 作为无状态的节点，间接应用 ReplicaSet 即可，每个 Pod 反对程度扩大。

目前公司曾经有业务应用 Pulsar on Kubernetes，如果 bookie 应用 Local Storage Volume，对 Pulsar 的性能根本没有影响。