Apache Pulsar本身没有直接的“广播模式”,即消息在发布后会被所有消费者接收的功能(类似于Kafka的“广播语义”或在RocketMQ中通过广播消费实现的方式)。然而,通过灵活的订阅功能,我们可以模拟广播模式来实现类似的效果。

Pulsar的订阅模型回顾:

Pulsar中有四种主要的订阅类型:

  • Exclusive – 独享订阅,一个订阅仅允许一个消费者。
  • Failover – 故障转移订阅,多个消费者订阅一个名称,但只有一个处于活动状态。
  • Shared – 共享订阅,多个消费者会分流消息。
  • Key_Shared – 按键共享订阅,消息根据 key 有序地分布给特定消费者。

但是这些订阅模型都是在一个订阅(Subscription)范围内工作的,并不能直接实现消息广播到所有消费者。


模拟广播模式的实现

即使Pulsar没有直接的“广播模式”,我们可以通过以下两种方法来实现类似的效果:

方法一:使用多个独立订阅名称

对于广播场景,我们可以为每个消费者创建一个独立的订阅名称,保证每个消费者都能够获取到全部消息。例如,Topic可以是 my-topic,消费者分别使用订阅名称 subscription1, subscription2, subscription3 等。
示例代码(Golang):

consumer1, err := client.Subscribe(pulsar.ConsumerOptions{
    Topic:            "my-topic",
    SubscriptionName: "subscription1",
    Type:             pulsar.Exclusive, // 订阅类型可以根据需求选择
})
if err != nil {
    log.Fatal(err)
}

consumer2, err := client.Subscribe(pulsar.ConsumerOptions{
    Topic:            "my-topic",
    SubscriptionName: "subscription2",
    Type:             pulsar.Exclusive, // 订阅类型可以根据需求选择
})
if err != nil {
    log.Fatal(err)
}

通过多个订阅(Subscription),每个消费者都可以独立接收到同一个Topic的所有消息,实现了消息的“广播”效果。

方法二:使用多路复用的额外逻辑

将消息发送到多个Topic,或者在应用层进行二次广播。比如:

  • 在生产者端发送消息到多个共享的广播Topic。
  • 在消费者端订阅这些广播Topic进行消息消费。

这种方式会轻微增加生产端发送的消息数量,但能更明确地设计广播逻辑。


注意事项

  1. 资源开销

使用多个独立的订阅(或者多个Topic)的方式会额外增加系统开销,比如元数据管理、存储和网络带宽等。

  1. 消费者的独立消费

每个消费者独立消费同一个消息时,消息的重复性是设计目标之一。也就是说,每个订阅的消息不会共享,不会被分流。

  1. 适合场景

类似的广播模式适用于以下场景:

  • 多个消费者需要独立处理消息。
  • 每个消费者对消息的处理逻辑完全独立,没有队列中的负载均衡需求。

总结

虽然Pulsar没有直接的广播模式,但通过独立订阅、多Topic等方式,可以模拟广播场景。同时也可以根据你的实际使用情况选择合适的订阅机制。如果广播模式需求较为明确并且要优化资源,RocketMQ的广播模式可能更简单直接。



pulsar 有广播模式吗插图

关注公众号:程序新视界,一个让你软实力、硬技术同步提升的平台

除非注明,否则均为程序新视界原创文章,转载必须以链接形式标明本文链接

本文链接:http://folen.top/2025/09/14/pulsar-2/