Pulsar中Exclusive订阅是否比Shared订阅资源效率更高？

同业务场景、同消费吞吐量下，Exclusive订阅的内存占用确实比Shared订阅低30%~60%，资源效率更高，但两者适用场景有明确边界，不建议单纯为了节省资源盲目切换。

• 架构逻辑带来的固有开销差：Exclusive是独占模式，同一个订阅仅允许1个消费者接入，Broker侧不需要维护多消费者的消息分发映射、消费重平衡状态、消息归属校验元数据，消费者侧也不需要同步同订阅组下其他节点的状态，这部分是两者开销差的核心来源。
• 重试逻辑的额外开销差：你当前代码开启了RetryEnable: true配置，Shared模式下需要为每一条待重试、待确认的消息维护所属消费者标记、重试次数、死信路由信息，消息堆积量上涨时这部分元数据内存会线性增长；而Exclusive模式下所有消息都归唯一消费者所有，重试逻辑不需要做归属判定，元数据结构简单，额外开销极低。
• 预缓存策略的开销差：Shared模式为了保证多消费者负载均衡，Broker和客户端都会预拉取缓存一部分消息做调度，当消费速度滞后于生产速度时，这部分缓存的内存占比会非常高；Exclusive模式的预缓存只需要服务单个消费者，缓存队列长度可以压得很低，不会产生冗余的调度缓存开销。

• Exclusive模式不支持同订阅下多消费者水平扩容，如果当前业务的消费吞吐量单节点无法承载，切换后会直接出现消费堆积，甚至新消费者无法成功接入订阅。
• 如果业务必须支持多消费者并行消费，不用直接切换订阅模式，可以先调整参数降低Shared模式的内存占用：
  • 调小客户端ReceiverQueueSize配置，默认值是1000，可根据实际消费速度降到200~500，减少客户端预拉取缓存的消息量
  • 开启批量消费、批量确认，降低单条消息的元数据维护开销
  • 合理设置最大重试次数，及时将多次消费失败的消息打入死信队列，避免无效重试消息长期占用内存

仅需要修改订阅类型参数即可，原有重试逻辑可正常保留：

pulsarConsumer, err := pulsarClient.Subscribe(pulsar.ConsumerOptions{
        Topic:                       topicName,
        SubscriptionName:            "test",
        Type:                        pulsar.Exclusive,
        RetryEnable:                 true,
    })

切换前务必在测试环境验证单节点消费能力是否匹配业务流量峰值，避免线上出现消费堆积故障。

内容的提问来源于stack exchange，提问作者CharmCcc