Pulsar凭什么成为流处理消息队列新宠

可视化演示

展示Pulsar核心优势：计算存储分离架构、四种订阅模式、与Kafka对比选型。切换模式查看不同维度。

架构革新

快递物流园里，决定每天能处理多少包裹的，是分拣台和仓库两个环节的短板。传统 Kafka 像一座“仓配一体”老楼——货架、分拣台挤在同一层，想多加一台分拣机，得先搬走楼里的货。Pulsar 则把物流园拆成两个独立系统：分拣台（Broker）只负责接单和派单，立体仓库（BookKeeper）只负责存包裹。这种“计算存储分离”的架构，是 Pulsar 一切优势的地基。

在 Pulsar 中，Broker 是无状态服务，不保存任何消息数据；消息以 segment 形式写入 BookKeeper 的 ledger 中。消费者要从哪个 topic 读，Broker 临时去仓库取，读完数据仍留在仓库。Kafka 的每个 broker 必须带着分区副本，所以扩缩容总伴随数据迁移。

这样一来，你不用担心仓库放不下还要给所有分拣台搬家；哪边缺，扩哪边，这就是 Pulsar 架构革新的价值。

弹性扩容

双十一快到了，分拣台不够用，你只需要在空地上搭几张新分拣台。在 Pulsar 中，新 Broker 启动后从元数据服务认领 topic，不需要复制任何存量数据，所以加机器以秒计。Kafka 加 broker 时需要重新分配 partition 和副本，数据搬迁往往以小时计。

Pulsar 的存储层缩容同样灵活。因为数据在 BookKeeper 里，Bookie 节点可以逐步下线并让 ledger 自动重新分布。计算层与存储层互相不绑架，弹性伸缩自然更快。

物流园的双十一不再可怕：先加分拣台顶住峰值，再去扩仓库容量，两边互不拖累。

多租户隔离

大型物流园不会让所有快递公司共用同一个库区，而是给每家租户划分独立库区，货架、道闸、月台分开管理。Pulsar 的多租户模型也这样：tenant 是快递公司，namespace 是库区，topic 是货道。管理员可以为每个 namespace 设置存储配额、消息速率和权限。

一台 Pulsar 集群可以同时服务多个业务团队，每个团队只看得见自己的租户。某个团队流量暴涨时，最多触到自己的配额上限，不会挤爆邻居的库区。Kafka 要实现类似隔离，通常需要为每个团队单独铺集群，运维成本高出一大截。

库区门禁管好了，几十个团队共用一套物流园也不会互相串货。这就是多租户隔离的价值。

订阅模式

同一个 topic 里的消息，可以像包裹一样有不同的取件方式。独占订阅是只请一个人签收；故障转移是正选签收人不在时备选人顶上；共享订阅是十个人一起拆包裹，谁有空谁拿；KeyShared 是按收货地址分人，同一个地址永远由同一个人负责，保证同一 key 的消息不乱序。

多订阅模式让 Pulsar 比 Kafka 灵活得多。Kafka 的消费组本质上更像故障转移加共享的混合体，但无法在同一份数据上按需切换。Pulsar 在消费端可以随时创建不同订阅，互不影响。

取件方式可以按需换：要严格单播就独占，要高吞吐就共享，要保序又高吞吐就 KeyShared，一个系统全部搞定。

数据可靠性

仓库收货时不是把包裹随手一放就告诉商家“已签收”，而是同时放进好几个货架，至少有两个货架回复“放好了”，商家才收到成功回执。BookKeeper 的 ack quorum 就是这个“至少两个”的签收阈值。

Pulsar 的每个消息条目会写入 write quorum 个 Bookie 节点，拿到 ack quorum 个节点的确认后才告诉生产者成功。只要故障节点数不超过 ack quorum 减一，至少还有一个已确认的副本存活，消息就不会丢。

确认签收机制让物流园不必等所有货架都回话才告诉商家，既保证不丢货，又保住响应速度。

分层存储

仓库容量有限，把几个月前的包裹打包送去地下档案室，取件时再按编号流式调取。Pulsar 的分层存储把老 segment 卸载到 S3/HDFS，BookKeeper 只保留热数据，topic 的保留时间从“几周”变成“长期甚至无限”。

分层存储对 AI 场景尤其有用。训练样本需要回溯 90 天甚至更久，把 90 天前的数据全放 BookKeeper 成本太高。Pulsar 自动把冷 segment 上传对象存储，消费者依然能从同一个订阅里读历史消息，不需要重新搭一套离线管道。

档案室解决了仓库爆仓问题，历史消息不再需要忍痛删除，回溯窗口由成本决定，而不是由架构决定。

跨域复制

一个物流园不够，在全国建两个园，面单数据异步同步。Pulsar 的跨地域复制也是异步的：北京写一条消息，后台异步复制到上海。消费者在两个地域都能读到副本，实现多活和容灾。

跨地域复制让 AI 平台可以“就近读写”。例如北京和上海各部署推理服务，日志各自写入本地 Pulsar，再互相异步复制；某个地域故障时，另一个地域的消费者还能继续消费相同的数据。

双物流园互相同步，任何一边台风停电，另一边都能继续运转，这就是跨地域复制的底气。

AI 应用场景

Python 演示

import random  class Bookie:    def __init__(self, bookie_id):        self.bookie_id = bookie_id        self.entries = {}     def append(self, entry_id, data):        self.entries[entry_id] = data     def read(self, entry_id):        return self.entries.get(entry_id)  class MiniBroker:    def __init__(self, bookies, write_quorum=2, ack_quorum=2):        self.bookies = bookies        self.write_quorum = write_quorum        self.ack_quorum = ack_quorum        self.entry_id = 0     def produce(self, data):        chosen = random.sample(self.bookies, self.write_quorum)        self.entry_id += 1        acks = 0        for bookie in chosen:            bookie.append(self.entry_id, data)            acks += 1        if acks >= self.ack_quorum:            return self.entry_id        raise RuntimeError("ack quorum not reached")     def read(self, entry_id):        for bookie in self.bookies:            value = bookie.read(entry_id)            if value is not None:                return value        return None  def main():    bookies = [Bookie(i) for i in range(3)]    broker = MiniBroker(bookies)    entry_id = broker.produce("hello pulsar")    print("produced entry:", entry_id)    print("message:", broker.read(entry_id))  if __name__ == "__main__":    main()

1. chosen = random.sample(self.bookies, self.write_quorum)随机选择 write quorum 个 Bookie 节点，模拟多副本写入。
2. bookie.append(self.entry_id, data)把消息条目写入一个 Bookie，相当于仓库里的一个货架完成上架。
3. if acks >= self.ack_quorum:只有确认数量达到阈值，才向生产者返回成功。
4. raise RuntimeError("ack quorum not reached")确认数不足时直接报错，确保不会给生产者虚假成功。
5. broker.read(entry_id)从任一存活 Bookie 读回数据，模拟故障后仍可恢复消息。

常见误区

面试题