Pulsar-架构与设计

临江蓑笠翁

已于 2024-02-21 18:50:40 修改

阅读量1.6k

点赞数 22

分类专栏：消息队列文章标签：架构

于 2024-02-18 20:04:58 首次发布

本文链接：https://blog.csdn.net/wlphlj/article/details/136150641

版权

消息队列专栏收录该内容

4 篇文章 0 订阅

订阅专栏

本文详细阐述了Pulsar的起源、设计特点、架构图，包括Broker、持久化存储和元数据管理，以及其关键功能特性如消息顺序性、重试机制、延迟队列等。介绍了四种消费订阅模式和生产访问模式，展示了Pulsar作为云原生消息队列的强大功能和弹性伸缩能力。

摘要由CSDN通过智能技术生成

一、背景和起源

随着云原生的兴起，对消息中间件的伸缩性和多租户隔离有了更高的要求。现有的消息中间件不支持多租户的隔离，但是有一定伸缩性，需要一定的迁移工具支持和手工操作。
Pulsar是下一代云原生分布式消息平台，采用存储和计算分离架构设计，支持弹性伸缩，支持多租户、持久化存储、多机房跨区域数据复制。

二、框架概述

1.设计特点

下一代云原生分布式消息流平台
单实例支持多集群，支持跨机房在集群间消息复制
极低的发布延迟和端到端延迟
支持超过百万的消息主题。
支持多种消息订阅模式（独占、共享和故障转移）
由BookKeeper 提供的持久化消息存储机制保证消息传递
由轻量级的 serverless 计算框架 Pulsar Functions 实现流原生的数据处理。
基于 Pulsar Functions 的 Server less connector 框架 Pulsar IO 使得数据更易移入、移出
Apache Pulsar。
支持冷热数据分级存储

2.框架适用场景

适用于多租户、云服务场景
适用于业务波动比较大、需要弹性伸缩场景

三、架构图

一个Pulsar实例有多个Pulsar Cluster组成，Pulsar Cluster之间可以进行消息复制。
Pulsar Cluster整体架构和组成如下，其中Broker为无状态服务，用于发布和消费消息，BookKeeper用于存储。

Broker集群：用于处理producer发出的消息；将消息存储到BookKeeper集群；将消息分配给consumer；处理集群协调任务。
BookKeeper集群：用于消息持久化存储。
Zookeeper集群：用于处理多个Pulsar集群之间的协调任务。

1.Broker

主要包含以下部分：

HTTP服务器：主要是提供系统管理接口、topic查找接口
Dispatcher：异步TCP服务器，用于数据传输
Managed Ledger：用于缓存从BookKeeper读取的消息

Broker是无状态服务的计算节点；可以通过增加Broker来增加系统的吞吐量；某个Broker节点负载过高，可以将负载迁移到其他Broker节点。

2.持久化存储（Persistent storage）

Pulsar采用BookKeeper作为持久化存储组件。其中Bookie为数据的存储节点，采用分片机制。Bookie支持扩缩容，在扩容过程中不需要将已持久化数据迁移到新存储节点。

3.Pulsar元数据（Metadata store）

Pulsar元数据和BookKeeper元数据可以共享一个Zookeeper集群，也可以使用不同集群。Pulsar使用Zookeeper来进行元数据存储、集群配置和协调。

四、功能特性

1.消息顺序性

可以支持分区顺序性，生产者通过指定的key将消息发送到固定分区，消息订阅模式需要选择独享模式、灾备模式、key共享模式。

2.消息回溯

pulsar默认删除已经被所有Consumer确认消费完成消息，可以通过配置保留已经被消费完成的消息。

3.消息去重

通过服务器设置可以保证消息不会重复持久化存储，保证存储的幂等。

4.消息重投递

消息投递失败，会进行重新投递

5.消息重试

消息消费失败后消息会重新消费

6.消息TTL

支持消息生存期

7.延迟队列

支持任意时间延迟的消息

8.重试队列

重试队列是消费失败后，消息会重新投递到此队列，重试队列按照消费组进行设置的。

9.死信队列

重试次数达到一定次数后，会将消息投递此队列

10.消息语义

支持Exactly Once消息语义，消息确定被写入一次。producer保存发送失败消息再次发送，服务端保证重试多条消息只存储一次。

五、设计原理

1.消息去重

消息去重是指即使消息被Producer多次投递到Broker，也只会被持久化一次。Pulsar可以通过Broker配置开启消息去重功能，不需要应该代码去保证。
实现原理：

Producer每个消息都有一个递增的唯一SequenceId
Broker针对每个Producer保存已经接受到的最大SequenceId和已经持久化的最大SequenceId
Broker接收的消息中SequenceId大于以上SequenceId，则正常处理；如果小于或者等于则为重复消息，直接返回Ack确认

2.消息重试

如果消费组中设置消息主题可以重试，则会（以主题和消费组为度）创建重试队列和死信队列；其中重试队列名称格式为TopicName-SubscriptionName-RETRY；死信队列名称格式为TopicName-SubscriptionName-DLQ；
整体流程为：

消费失败后，会将消息作为延迟消息重新投递到重试队列，利用延迟消息特性使Consumer延后一段时间重新消费
如果重新投递到重试队列超过一定次数，则会把消息投递到死信队列

在这里插入图片描述

3.延迟队列

Broker针对topic每个分区，按照subscription维度维护了DelayedDeliveryTracker优先级队列，队列中以消息的延迟投递时间进行升序排列。

延迟消息投递到Broker后，不用特殊处理直接持久化
消费时，优先检测DelayedDeliveryTracker是否有消息需要消费（延迟投递时间已到）；如有则消费；如果没有则消费正常队列消息
消费正常队列消息，如果消息为延迟消息，则需要把消息索引存入到DelayedDeliveryTracker优先级队列

注意：只有在共享模式和key共享模式才支持延迟队列