Pulsar实战：云原生消息队列存算分离架构解析

我最早关注Pulsar，是在一次公司内部的技术选型讨论上。当时团队正在为一个实时数据中台项目挑选消息中间件，Kafka、RabbitMQ来回过了好几轮，突然有同事抛出一句：要不看看Pulsar？说实话，那时候我连这个名字都念不顺溜，更没想过它会在后来的大促链路里成为扛住千万级消息洪峰的关键角色。后来花了两个周末把官方文档啃完，又在小规模集群上跑了压测，我才意识到Pulsar身上那种"云原生消息队列"的底气不是营销话术——它把存储和计算彻底拆开，用Apache BookKeeper做底层存储，Broker只负责消息路由和负载管理，这种架构设计让很多困扰Kafka多年的老问题直接消失。如果你正面临消息队列选型，或者被多租户、跨地域复制、存储成本这些需求反复折磨，这篇"初识"应该能帮你建立对Pulsar的核心认知。

1. 从Kafka的痛到Pulsar的香：选型背后的思考

1.1 传统消息队列在云原生时代的尴尬

先聊一个最直观的痛点：Kafka的存储和计算是绑在一起的。每个Broker节点既是计算单元又是存储单元，分区一旦创建，它的Leader和副本就固定在某些节点上。写入流量大了，你想扩容，新节点加入后需要做分区重平衡，这个过程中副本迁移会占用大量网络和磁盘I/O，搞不好还会影响在线读写。当时我们有个大Topic单日写入量在上亿条，分区数已经堆到上百个，每次扩容都是一场心惊肉跳的运维大考。

RabbitMQ的情况又不太一样。它擅长做复杂路由和灵活的消息模式，但吞吐量到了千万级就有点吃力，消息堆积时内存和磁盘的表现也不够理想。更麻烦的是，它默认把消息存在内存或本地磁盘，节点挂了恢复起来非常费劲。你可能会说，用镜像队列不就完了？但多节点同步带来的网络开销和性能损耗，在高峰期真的会让人怀疑人生。

这些传统中间件在物理机时代够用，但放到云原生环境里就尴尬了。容器调度要求组件能随时随地弹性伸缩，存储要么挂云盘要么交给独立存储服务，而Kafka这种"计算存储一体"的模型，Pod漂移、节点故障都会牵一发动全身。Pulsar之所以能进入视野，就是因为它从底层架构上改变了游戏规则：计算节点不存数据，数据节点不碰计算。

1.2 Pulsar到底是个什么来头

Pulsar是Apache软件基金会的顶级项目，由Yahoo在2013年左右孵化、2018年捐赠给Apache，现在已经是消息队列领域不可忽视的一股力量。它的核心卖点可以浓缩成几句话：采用存算分离的分层架构，Broker是无状态的，消息数据交给BookKeeper集群持久化；原生支持多租户，用Property/Namespace做隔离；支持跨地域复制，可以在多个数据中心之间同步消息；同时兼容Kafka API，很多客户端不用改代码就能切过来。

一开始我对这些特性保持怀疑，毕竟"什么都能干"的东西往往什么都干不好。但等我真正搭了一套三节点的Pulsar集群跑业务压测，才明白它的架构优势确实能兑现。最直观的感受是扩容：加Broker只需要把新的无状态节点接进来，不用搬任何数据；加存储节点也只需要等BookKeeper自动做数据重分布。整个过程中，消费者几乎感知不到抖动。这种体验在Kafka上我是从未有过的。

2. Pulsar核心架构拆解：为什么它敢叫云原生

2.1 三层架构：Broker、BookKeeper、元数据服务

Pulsar的部署架构可以粗略看成三层。最上层是Broker，它相当于一个轻量的路由器，负责接收生产者的消息、把消息写入存储、再推送给消费者，同时管理各种订阅状态。Broker本身不保存消息数据，所以它是无状态的，可以随意增删和滚动升级。

中间层是BookKeeper集群，每个节点叫Bookie。这里才是消息数据的真正归宿。Broker把消息按Segment为单位写入Bookie，Bookie负责数据的持久化、复制和恢复。BookKeeper本身就是Apache旗下的分布式存储系统，专为日志类数据设计，具有低延迟、高可用、强一致的特性。

最底层是元数据服务，Pulsar用ZooKeeper（在较新版本中也可用etcd）管理整个集群的元数据，比如Broker的注册信息、Topic的分布、租户权限配置等。不过ZooKeeper只存元数据，不存消息，压力不大。

这三层各司其职的架构，让Pulsar在云原生环境里如鱼得水。Broker可以做成无状态Pod，配合Kubernetes的HPA按流量自动扩缩容；Bookie需要稳定存储，就挂上云盘的StatefulSet；ZooKeeper当标准有状态服务管理。哪一层出问题就单独扩容哪一层，完全不互相牵扯。

2.2 Segment机制：一份消息数据如何被优雅地管理

BookKeeper存储消息的方式很巧妙，它把每个Topic的消息流切分成一个个Segment，每个Segment内部又包含多个Ledger片段。写入时，多个Bookie组成一个Ensemble，消息被同时写入多个Bookie形成副本，默认是2副本，也就是同一份数据写两份，保证一个节点挂了数据不丢。

这个设计跟Kafka的Partition有本质区别。Kafka里一个Partition是一个连续的日志文件，只能由Leader节点接收读写；而Pulsar的Topic底层是一个Segment列表，每个Segment可以分布在不同的Bookie组合上，不同Segment甚至可以走不同的副本策略。也就是说，一个Topic的写入压力天然就被分散到了多台存储节点上，不存在单点瓶颈。

Segment还有一个特别实用的特性：可去重。Kafka的Partition文件只能顺序追加，想清理旧数据得做日志压缩或者整段删除；Pulsar则可以把不再被任何订阅消费的Segment直接剥离释放。配合可配置的留存策略（可以按时间、按大小、按消息条数设置TTL），清理存储再也不用像Kafka那样手动触发什么cleanup脚本。我印象很深的是一次压测后，发现旧Topic占用了几百GB空间，在Pulsar里设置了两条策略后，旧数据自动老化，存储曲线肉眼可见地往下掉，而在Kafka里我得小心翼翼评估会不会影响到在线消费。

2.3 为什么存算分离是云原生消息队列的命根子

云原生不是简简单单把应用塞进容器就完事，它讲究弹性、韧性、可观测性和自动化运维。传统消息队列的问题在于，存储和计算耦合导致弹性能力被锁死。你想加存储，得连计算一起加；你想缩容计算节点，又怕上面的分区数据没地方放。这样算下来，虽然节点都是容器化的，但整体的"卷"被绑住了，扩缩容并没有真正变灵活。

Pulsar把存储抽离出去之后，Broker变成了一种近乎"瞬间可替换"的资源。流量高峰来了，Kubernetes过HPA或KEDA让Broker副本从3个拉到10个，只要把配置里的集群接入地址指过去，它们马上就能分担负载。流量低峰了，缩回2个也行，消息数据还在Bookie里躺着，不会有任何丢失。存储侧的Bookie则可以通过CRD管理，按使用率扩容，也没必要跟着计算流量走。

我在生产环境里做过一次实验：在业务高峰期给Broker扩容，消费者端几乎没感觉到任何波动，消息延迟曲线稳得很。换做Kafka，光是把某个分区副本迁移到新节点就够折腾半天，期间还会伴随ISR收缩、Leader选举这些风险操作。这就是存算分离在真实场景下的价值，也是它配得上"云原生"三个字的原因。

3. 核心概念与消费模式实操：从零开始理解Pulsar

3.1 先搞懂这五个概念再上手

接触Pulsar时，最容易被一堆专业名词劝退。我建议你把下面这五个核心概念先记在脑子里，后面所有的操作都不会跑偏。

• Tenant与Namespace：多租户隔离的单位。Tenant相当于一个租户，Namespace相当于租户下的一个命名空间，一个Tenant可以建多个Namespace。你可以给不同业务线分配不同的Namespace，从权限到配额都能单独控制。
• Topic：消息的通道，生产者和消费者都围绕Topic来收发消息。Topic分为持久化Topic和非持久化Topic，默认是持久化的。
• Producer：消息的生产者，负责把消息发到Topic。Pulsar支持同步发送、异步发送，还支持批量发送，批量模式能大幅提升吞吐。
• Consumer：消息的消费者。Consumer需要绑定一个Subscription（订阅）才能收消息，先订阅后消费。
• Subscription：一个Topic下可以有多个订阅，每个订阅内部的消费者共享该订阅的所有消息，不同订阅之间相互独立。这个概念很像一个Topic派生出的消费视图，同一个Topic可以被多个业务方以不同方式重复消费，互不影响。

有个小细节特别值得夸：在Kafka里面，同一个消费者组里的消费者必须通过group.id协同，而Pulsar的Subscription天然承担了"消费组"的职责。实现同一个消费逻辑，Pulsar只需要给消费者指定同一个Subscription，理解起来直观很多，也不用额外维护一堆consumer group的状态。

3.2 四种订阅模式怎么选

Pulsar的订阅模式是它区别于多数消息队列的一大亮点。同样一个Topic消息流，可以按不同订阅模式独立消费，互不干扰。

Exclusive独占模式：整个Subscription只允许一个消费者连接，一旦有多个消费者持有同一个Subscription，会直接报错。这种模式适合要求严格顺序的场景，比如账单流水处理。

Failover灾备模式：订阅里可以挂多个消费者，但同一时刻只有一个消费者在接收消息，另外几个作为备用。如果主消费者宕机，Pulsar会自动把订阅切换到下一个消费者。它比Exclusive好在多了一层容灾能力，顺序性依然有保障。

Shared共享模式：消息被轮流分发给该订阅下的所有消费者，类似负载均衡。这种模式吞吐量最高，适合推短信、发邮件、做数据管道这类对顺序不太敏感的任务。如果某个消费者处理慢，其他消费者可以继续抢消息，不会整体卡住。

Key_Shared键共享模式：这是共享模式的一个变种，Pulsar会按消息的Key哈希结果投递给特定消费者，保证同一个Key的消息总是被同一个消费者处理。它既保证了单Key顺序，又能把压力分摊到多个消费者，是订单事件、用户事件这类场景的绝配。

我实践下来最常用的就是Shared和Key_Shared两种。日常削峰填谷直接无脑Shared；涉及用户维度的状态更新，就用Key_Shared把userId作为消息的Key。需要说明一点，Key_Shared是有额外开销的，它需要Broker维护Key与Consumer的映射关系，如果Key数量特别大，会消耗一点Broker的内存，生产环境上要稍微留意。

3.3 ack机制与重复消费这个老大难

说到消息队列，重复消费问题几乎必然被提上日程。Pulsar的设计跟Kafka不太一样，它有一个Ack确认机制：消费者处理完一条消息后，要显式向Broker发送确认，Broker才会把消息从该订阅的待消费状态里移除。

问题恰恰出在"处理完"和"发送确认"之间的窗口。如果业务处理完了，进程还没来得及发ack就崩溃了，Broker就会认定这条消息没被消费成功，等消费者重启后重新下发一遍，于是重复消费就发生了。当时我们上线Pulsar头一天，就收到了账单系统重复扣款的告警，排查后确认是消费者在发送ack前JVM发生了Full GC，消息被重新投递了一次。

面对重复消费，我的建议是两条腿走路。第一，在代码层面尽量把"处理"和"确认"之间的距离缩短，处理完立刻ack，不要攒一批最后统一确认，避免崩溃窗口过大。第二，消费端做幂等，这是必须的兜底手段。数据库里加唯一约束、Redis里记处理标记、或者给消息带幂等ID，选一种适合你业务的方式，反正不能天真地认为消息只会投递一次。

Pulsar还有个超时机制需要留意：消费者拿到消息后必须在AckTimeout时间内确认，否则Broker会把消息重新投递给其他消费者。如果你在Shared模式下AckTimeout设得太短，而业务处理偶尔超过这个时间，就会引发"消息明明在处理，却不断被其他消费者拿走"的连环问题。这个参数我建议设成正常处理耗时的2~3倍，宁可让重复多一点，也别制造大量无用重投。

4. 本地部署与第一行代码：跑通一个真实的Pulsar

4.1 五分钟用Docker启动单机Pulsar

如果你只是入门体验，完全没必要一上来就搭集群，Pulsar官方提供了单机模式（Standalone），跑一条命令就能把Broker和BookKeeper都启动起来。我最推荐的方式是用Docker，省去装本地依赖的麻烦。

bash复制docker run -d --name pulsar \
  -p 6650:6650 \
  -p 8080:8080 \
  apachepulsar/pulsar:3.3.0 \
  bin/pulsar standalone

命令跑起来后，6650端口用于客户端收发消息，8080端口是HTTP管理接口。稍等十几秒，浏览器访问http://localhost:8080/admin/v2/tenants，如果返回一个空数组或者正常JSON，说明服务已经起来了。

这里有个坑想提醒你：单机模式的BookKeeper数据默认落在容器内的/pulsar/data目录，容器一删数据全没。如果你只是想体验两句，无所谓；如果想在本地做点小实验，建议把数据目录挂载到宿主机：

bash复制docker run -d --name pulsar \
  -p 6650:6650 \
  -p 8080:8080 \
  -v pulsar-data:/pulsar/data \
  apachepulsar/pulsar:3.3.0 \
  bin/pulsar standalone

另一点是内存占用。Pulsar是基于Java的，JVM启动默认占不少内存，单机模式下建议给Docker至少4GB内存，否则BookKeeper可能因为堆外内存不足直接启动失败。我第一次试的时候只给了2GB，日志里疯狂报内存分配错误，找了好半天才发现是容器内存配额的问题。

4.2 用Java客户端完成一次消息收发

环境跑起来后，最重要的就是写代码验证链路。我习惯用Maven工程，首先引入依赖：

xml复制<dependency>
    <groupId>org.apache.pulsar</groupId>
    <artifactId>pulsar-client</artifactId>
    <version>3.3.0</version>
</dependency>

然后写一个最基础的生产者：

java复制PulsarClient client = PulsarClient.builder()
        .serviceUrl("pulsar://localhost:6650")
        .build();

Producer<String> producer = client.newProducer(Schema.STRING)
        .topic("persistent://public/default/my-topic")
        .create();

for (int i = 0; i < 10; i++) {
    producer.send("hello pulsar: " + i);
}
producer.close();

这里注意Topic的完整格式，它包含了Tenant、Namespace和Topic名三部分：persistent://public/default/my-topic。其中public是默认租户，default是默认Namespace，不写全的话客户端也会自动补全，但建议养成写全路径的习惯，多租户环境下才不会串业务。

消费者的代码同样简洁：

java复制Consumer<String> consumer = client.newConsumer(Schema.STRING)
        .topic("persistent://public/default/my-topic")
        .subscriptionName("my-subscription")
        .subscriptionType(SubscriptionType.Shared)
        .subscribe();

while (true) {
    Message<String> msg = consumer.receive();
    System.out.println("收到消息: " + msg.getValue());
    consumer.acknowledge(msg.getMessageId());
}

重点留意acknowledge这一步。很多新手收到消息打印出来就行了，忘了确认，结果重启后消息又重复来一遍，这就是前面聊过的重复消费。发消息的代码可以随便写，但消费代码务必养成"收到消息立刻处理、处理完立刻ack"的习惯。

4.3 CLI工具才是排查利器

跑通Java代码还不够，生产上你不可能每次排查都写个程序。Pulsar提供的pulsar-admin和pulsar-client两个命令行工具，一定要熟。前者用于管理集群资源，后者用于收发消息测试。

比如查看一个Topic的订阅情况：

bash复制docker exec -it pulsar bin/pulsar-admin topics stats persistent://public/default/my-topic

这个命令会输出消息速率、存储大小、每个订阅的积压数量等信息，排查问题第一步基本都是它。想快速消费几条消息验证链路通不通，就用：

bash复制docker exec -it pulsar bin/pulsar-client consume persistent://public/default/my-topic -s test-sub --num-messages 5

我现在排查线上消息问题，流程基本是：先stats看整体状态，然后用consume命令挂一个独立订阅去试消费，确认Broker和存储层没问题，再回头查业务消费者的日志。这个顺序能帮你快速缩小故障半径。

5. 常见问题与排查技巧实录：那些我踩过的坑

5.1 消息重复消费的排查套路

作为消息队列最经典的问题，重复消费值得单独拿出来讲透。Pulsar里的重复消费通常有几个原因，我先列出来供你排查时对照。

第一，业务处理超时引发重投。消费者拿到消息后，处理耗时超过了AckTimeout，Broker就认为消费失败，把消息重新投递给同一个或另一个消费者。有时候你会在日志里发现同一批消息被处理了两次，但时间间隔正好在超时窗口附近。解决办法是调大AckTimeout，或者改用NegativeAck主动告知Broker"我暂时处理不了，请稍后重投"，而不是干等超时。

第二，消费者崩溃引起消息重新派发。Consumer和Broker之间的连接断开后，该消费者已经接收但未确认的消息，会被重新标记为待消费状态。这种情况在Pulsar日志里通常表现为Consumer连接断开、随后消息再次下发。解决思路除了幂等兜底外，还可以让消费端把ack频率提高，把未确认窗口压缩到最小，降低崩溃后重投的范围。

第三，订阅模式切换导致的混乱。如果一个Subscription先用了Exclusive模式，后来又改成Shared模式，之前保留的消费位点可能和现有消费者的状态不一致，也会引发重复。我那次线上事故就是运维同学在配置中心改了订阅类型，没排查存量消费者，结果半个小时后一堆重复告警。所以订阅模式变更前，一定要确认当前没有消费者在运行，或者先把订阅删除再重建。

排查重复消费问题时，单靠日志很难全貌定位。我的建议是给每条消息塞一个unique_id，在生产者端生成，消费者把处理过的ID记录在Redis或数据库里。一旦出现重复，你就能很快统计出重复率以及对应的时间窗口，再去查对应的Broker日志和客户端日志。

5.2 消息积压严重时怎么快速恢复

积压是消息队列绕不开的话题。Pulsar里积压的定义是，某Subscription的消费位点远落后于生产位点。造成积压的原因通常是消费者处理能力不足，或者消费者宕机了。

排查积压，我习惯分三步走。第一步，用pulsar-admin topics stats查看该Topic下每个Subscription的msgBacklog和backlogSize，确认积压主要集中在哪个订阅。第二步，看这个订阅的消费者数量、接收速率和处理速率，确定是消费者不够还是单个消费者处理太慢拖累了整体。第三步，针对原因下手。

如果是消费者数量不足，直接横向扩容消费者实例就行，注意Shared模式下新增消费者会立刻参与消息分发，扩容效果立竿见影。如果是单个消费者处理太慢，就得优化业务逻辑，比如把写数据库改成批量写、把远程调用改成异步。还有一个临时救急方案：临时增加一个订阅，从最早消息开始快速把数据消费到另一个缓冲区，等主订阅追上进度再切回来。这个操作不影响主订阅的位点，安全性比较高，我做过好几次，把大促后的积压从几个小时压缩到十几分钟。

5.3 顺序消息到底该怎么保

面试八股文里常说顺序消息，但很多人落地时都会踩坑。Pulsar里如果你用Exclusive或Failover订阅，并且只有一个消费者，天然就是全Topic顺序的，代价是吞吐量受限。需要更高吞吐又要保顺序时，就得靠Key_Shared。

使用Key_Shared的关键是给消息设置好Key。生产端这样写：

java复制MessageId msgId = producer.newMessage()
        .key("user-1001")
        .value("{\"action\":\"login\"}")
        .send();

消费者端正常用Key_Shared订阅即可。这里有一个容易忽略的点：如果你创建消费者时忘记指定subscriptionType(SubscriptionType.Key_Shared)，默认是Exclusive，第二条消费者一连接就会报"only one consumer allowed"的错。另外，Key的数量多少对性能影响很大。Key越少，分配到单消费者的消息越多，一旦某个消费者卡住，这个Key的所有后续消息都被堵住；Key越多，Broker的映射表开销越大。一般建议让Key的基数保持在消费者数量的5到10倍，既平衡负载，又留出容错空间。

5.4 故障排查速查表

这张表算是我经验的高度浓缩，覆盖了日常80%以上的Pulsar运维问题。遇到难题时，先对照现象找原因，再结合pulsar-admin命令看具体数据，基本能在半小时内定位到方向。

6. Pulsar和Kafka怎么选：一次坦率的对比

6.1 关键差异对照表

我在团队里被问得最多的就是：Pulsar比Kafka好在哪？直接摊开说，两个产品都是优秀消息队列，但设计哲学不同。Kafka追求极致的吞吐和生态，Pulsar则押注架构灵活性和多租户能力。下面这张对照表是我基于实践经验总结的，未必绝对客观，但胜在真实。

要说缺点，Pulsar也不是没有短板。它的架构比Kafka复杂，Broker、BookKeeper、ZooKeeper三套组件一个都不能少，运维门槛明显更高。社区和生态虽然增长很快，但相比Kafka还是略逊一筹，一些周边工具、第三方集成、文档案例的数量都有差距。另外，存算分离意味着消息要多一跳网络，延迟理论上会比Kafka本地读盘多零点几毫秒。不过现在很多云厂商用的BookKeeper都是同机架部署，网络开销几乎可以忽略，实测延迟依然维持在个位数毫秒级。

6.2 不同场景下的选型建议

选型归根到底看业务画像。如果你是做日志采集、大数据管道、离线数仓这种"大吞吐顺序追加"的场景，Kafka几乎是无脑选择，生态太成熟了，从生产端到消费端再到Spark Streaming、Flink的集成全是现成的。如果你更关心Spring Cloud Stream这种开发体验，RabbitMQ的灵活路由能力也依然很能打。

Pulsar则更适合这几类场景。第一，多租户平台型业务：你要给几十个内部部门提供消息能力，每个部门的数据隔离、配额管理、权限控制都要精细化，Pulsar原生多租户能让平台运维省很多心。第二，跨地域容灾与复制场景：业务分布在多个城市的数据中心，要求消息实时双向同步，Pulsar的Geo-Replication配置比MirrorMaker清晰得多。第三，存算分离后的成本控制场景：数据增长快但消费又下沉得慢，BookKeeper的Segment清理和分层存储（能把你冷的Topic数据卸载到S3或HDFS）能实打实地省钱。第四，你已经在云原生环境里跑Kubernetes，希望消息中间件能跟Pod的弹性调度完美配合，Pulsar的架构天然契合。

我个人还有个经验：如果你团队没有专门的中间件运维人力，Kafka显然更好维护，社区答案也多；但如果你们有资深中间件同学，愿意扛住初期学习成本去换取长线的架构红利，Pulsar值得重仓。选型从来不是找"最好的"，而是找"最适合你团队和业务现状的"。

最后说点掏心窝的话。Pulsar的学习曲线比Kafka陡不少，光是把Broker、BookKeeper、ZooKeeper的关系理清楚就够喝一壶。我当初啃文档时也很多次想放弃，但真正上手跑通一轮后，再回头看Kafka的运维难题，心态真的回不去了。云原生消息队列这个概念听起来很大，落到实践里其实就是"弹性、解耦、低成本"这七个字。如果你也在做选型，建议别光看官网指标，拿真实业务流量压一小时Pulsar，让数据替你说话。