首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Pulsar存储计算分离架构设计之Broker无状态

Pulsar存储计算分离架构设计之Broker无状态

作者头像
老周聊架构
发布2025-11-20 10:57:54
发布2025-11-20 10:57:54
1410
举报

一、前言

在分布式消息队列系统中,传统的架构模式如RocketMQ、RabbitMQ和Kafka等,通常将消息存储和消息处理逻辑集中在Broker节点上。这种模式虽然在一定程度上简化了系统设计,但在面对大规模数据处理和高并发访问时,会面临一些挑战,如单点故障、数据一致性、负载均衡以及扩展性等问题。为了解决这些问题,Apache Pulsar提出了一种全新的架构设计——存储计算分离。

二、Pulsar的存储计算分离的优势

2.1 存储与计算职责分离

Pulsar将消息的存储职责从Broker中剥离出来,交由专门的BookKeeper集群负责。BookKeeper集群采用分布式存储方式,确保消息数据的高可靠性和持久性。而Broker则专注于消息的处理和分发,不再承担存储任务,从而成为无状态节点。

2.2 灵活的负载均衡

由于Broker是无状态的,Pulsar可以根据集群的负载情况动态调整Broker与主题分区的对应关系。当某个Broker负载过高时,可以将其管理的部分分区迁移到其他负载较低的Broker上,从而实现负载均衡。这种动态调整机制大大简化了集群的管理和调度。

2.3 简化的故障恢复

在传统的消息队列系统中,如果某个Broker节点发生故障,需要找到与该节点数据一致的节点来接管其任务,这通常是一个复杂且耗时的过程。而在Pulsar中,由于Broker是无状态的,任何一个Broker都可以接管发生故障的Broker的任务,无需进行数据同步和一致性检查,从而大大简化了故障恢复过程。

2.4 易于扩展和维护

由于存储和计算职责的分离,Pulsar可以独立地扩展Broker集群和BookKeeper集群。当系统需要处理更多的消息时,可以简单地增加Broker节点来提高处理能力;当需要存储更多的消息时,可以增加BookKeeper节点来扩展存储空间。这种独立的扩展方式使得系统的维护和升级变得更加简单和高效。

2.5 高性能与可靠性

BookKeeper集群通过复制和分片技术确保消息数据的高可靠性和持久性。同时,Broker通过缓存机制减少对BookKeeper集群的访问频率,提高消息处理的性能。这种设计使得Pulsar在保持高性能的同时,也具备了极高的可靠性。

综上所述,Pulsar的存储计算分离架构通过将存储和计算职责分离,实现了灵活的负载均衡、简化的故障恢复、易于扩展和维护以及高性能与可靠性等特点。这种架构设计为分布式消息队列系统的发展提供了新的思路和方向。

三、Pulsar的存储计算分离的缺点

3.1 问题的本质未变

俗话说,“背着抱着一样沉”。在系统设计中,无论是否采用存储计算分离,系统需要完成的功能和解决的问题本质上是相同的。例如,在Pulsar中,尽管Broker相比于其他消息队列的Broker变得更加简单,但这并不意味着存储计算分离的设计解决了所有复杂问题。实际上,这些问题只是被转移到了BookKeeper存储集群上。

3.2 存储集群的复杂性

BookKeeper作为存储集群,依然需要解决数据一致性、节点故障转移、选举、数据复制等一系列复杂问题。因此,存储计算分离后,系统从单个集群变为两个集群,整体复杂度实际上有所增加。

3.3 性能损失

存储计算分离设计也会导致系统性能的一定损失。例如,在Pulsar中,当客户端从Broker消费一条消息时,Broker需要向BookKeeper集群请求数据,然后再返回给客户端。这个过程增加了网络传输和内存拷贝的次数,相比于直接从本地磁盘读取数据,性能会有所下降。

尽管存储计算分离会带来一定的性能损失,但相比于其带来的优点(如降低系统开发复杂度、提高系统的可扩展性和可维护性等),这种性能损失是可以接受的。特别是对于大部分业务系统来说,采用存储计算分离设计是非常划算的选择。

综上所述,存储计算分离设计在系统设计中具有其独特的优势和局限性。在决定是否采用这种设计时,需要综合考虑系统的具体需求、性能要求以及开发复杂度等因素。

四、Pulsar的生产者与消费者流程

4.1 Producer实例化

在这里插入图片描述
在这里插入图片描述

4.2 Producer发送消息

在这里插入图片描述
在这里插入图片描述

4.3 Consumer实例化

在这里插入图片描述
在这里插入图片描述

4.4 Consumer接收消息

在这里插入图片描述
在这里插入图片描述

五、Broker 模块

前置的一些分析我就大概说下,无非还是那一套,Client 与 Server 通过 Netty 进行通信,PulsarDecoder 包装了下,继承自 Netty 的 ChannelInboundHandlerAdapter (入站事件处理器的适配器类)

在这里插入图片描述
在这里插入图片描述

可以看下继承 Netty 那一套的 UML 图:

在这里插入图片描述
在这里插入图片描述

跟着源码可以看到这个方法:

代码语言:javascript
复制
org.apache.pulsar.broker.service.ServerCnx#handleSend
在这里插入图片描述
在这里插入图片描述

关键逻辑说明:

在这里插入图片描述
在这里插入图片描述

主要看 producer.publishMessage :

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

我们这里直接看持久化主题的,继续跟 publishMessage:

在这里插入图片描述
在这里插入图片描述

Broker 无状态的核心体现,也是Pulsar的存储计算分离架构的核心体现之一,这里很重要,划重点!!!

在这里插入图片描述
在这里插入图片描述

Broker 无状态的主要时序图:

在这里插入图片描述
在这里插入图片描述

消息从客户端到 Broker 的完整路径:

  • Broker 内部的处理流程(Producer → ServerCnx → Topic → ManagedLedger)
  • BookKeeper 写入机制(OpAddEntry → BookKeeper → Bookie)
  • 回调机制(addComplete → publishContext.completed)
  • 最终客户端收到确认

欢迎大家关注我的公众号【老周聊架构】,AI、大数据、云原生、物联网等相关领域的技术知识分享。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-07-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 老周聊架构 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、前言
  • 二、Pulsar的存储计算分离的优势
  • 三、Pulsar的存储计算分离的缺点
  • 四、Pulsar的生产者与消费者流程
  • 五、Broker 模块
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档