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

一、前言

在分布式消息队列系统中，传统的架构模式如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 图：

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

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）
• 最终客户端收到确认