Products
GG网络技术分享 2026-04-15 12:25 0
说实话，最近这技术圈儿里Apache Pulsar 真的是火得一塌糊涂。你要是还没听说过那可能真的要稍微补补课了。这不仅仅是个消息队列，真的，别把它跟那些老掉牙的 MQ 混为一谈。官方吹它是“下一代云原生分布式消息流平台”，听着挺玄乎吧？ 这就说得通了。 其实说白了它就是要把消息、存储、轻量化函数式计算这三样东西给揉在一起。而且， 最最核心的一点，也是它区别于 Kafka、RocketMQ 这些老大哥的地方，就是它的架构——计算与存储分离。这四个字，你得记住了这是 Pulsar 的灵魂。
咱们先来聊聊架构。传统的消息系统， 比如 Kafka，计算和存储是耦合在一起的，Broker 既要负责处理消息的读写，又要负责把消息存到磁盘上。这就有问题了你要是想扩容， PUA。 得连着存储一起扩，麻烦得很。而且一旦 Broker 挂了 那上面的数据也就跟着遭殃，虽然也有副本机制，但恢复起来总是让人提心吊胆。
但是 Pulsar 不一样。它把这两层给彻底拆开了。上面一层是 Broker， 专门负责计算，也就是处理连接、处理消息的收发；下面一层是 BookKeeper，专门负责存储，也就是老老实实把数据写到磁盘里。 开倒车。 这种设计简直绝了！你想增加吞吐量？加 Broker 就行，不用动存储。你想存更多数据？加 Bookie就行，不用动计算。这不就是云原生想要的弹性伸缩吗？
99113b38569747375e308d4276f1c5bc_
而且啊， Pulsar 的架构里还有一个叫 ZooKeeper 的东西，它是用来协调元数据的。所以整个集群跑起来虽然组件看着多了点，但其实各司其职，稳得很，摸个底。。
说到存储，就得好好唠唠 BookKeeper。这可是 Pulsar 的基石。BookKeeper 里比较核心的元素有三个：记录、日志段、日志流。别被这些名词吓到了其实挺好理解。
你可以把 Ledger 想象成一本账本，Producer 写进去的每一条消息就是 Entry。BookKeeper 负责把这些账本平安地存到多个 Bookie 节点上， 嚯... 保证不丢数据。它有个特点叫“写确认”，只有当消息写入到多个 Bookie并且返回确认了这才算写入成功。所以它的可靠性是杠杠的。
单个 Bookie 节点支持数千个 Ledger 并发读写，这高并发能力也是没谁了。而且它支持分层存储， 热数据在磁盘，冷数据可以扔到 S3 之类的云存储上，这成本一下子就下来了是不是很机智，太顶了。？
好，说完了底层的存储，咱们来看看上层怎么用。最核心的概念肯定是 Topic。Topic 就是一个通道，Producer 往里写，Consumer 从里读。这跟 Kafka、RocketMQ 差不多，冲鸭！。
但是！Pulsar 的订阅模式可就丰富多了。它有四种：Exclusive、Failover、Shared和 Key_Shared。 我跪了。 这四种模式各有各的用处，你要是选错了那业务逻辑可能就全乱套了。
咱们来看个表格， 对比一下这几种模式，一目了然：
| 模式 | 消费者数量 | 顺序性 | 核心说明 | 核心适用场景 |
|---|---|---|---|---|
| Exclusive | 1个 | 全量严格顺序 | 同一 Topic 仅允许一个消费者订阅，若多个消费者尝试订阅，直接抛出异常。消息按生产者发送顺序依次投递。 | 订单状态流转、 金融交易日志 |
| Failover | 多个 | 全量严格顺序 | 同一 Topic 可注册多个消费者，Broker 按消费者连接顺序排序，仅让“活跃消费者”处理消息，其他消费者作为备用。 | 支付通知、 风控告警 |
| Shared | 多个 | 无顺序 | 同一 Topic 可注册多个消费者，Broker 采用 Round-Robin 轮询机制分发消息，每条消息仅投递至一个消费者。 | 日志采集、 监控数据上报 |
| Key_Shared | 多个 | 同 Key 严格顺序 | 消息与消费者均绑定 Key，Broker 按消息 Key 的哈希值定向分发，同一 Key 的消息始终投递至同一个消费者。 | 用户行为分析、会话跟踪 |
本质上... 看到了吧？这四种模式大体上覆盖了所有的业务场景。你要是强顺序， 就用 Exclusive 或者 Failover；你要是高吞吐不 care 顺序，Shared 走起；你要是想兼顾顺序和吞吐，那 Key_Shared 就是为你准备的。
来一波... 光说概念太空泛了咱们直接上代码。这里有一段 Java 代码，演示了怎么创建一个 Key_Shared 模式的消费者。注意看注释，细节都在里面。
// 注意：Key_Shared 模式需配合 KEY_BASED 批处理构建器Producer producer = .topic .batcherBuilder // 按 Key 分组批处理 .create;Consume 歇了吧... r consumer = .topic .subscriptionName .subscriptionType // 指定键共享模式 .subscribe;// 发送带 Key 的消息.key.value).send;
这段代码其实挺有意思的。你看那个 `batcherBuilder`， 这是为了配合 Key_Shared 模式用的，保证同一个 Key 的消息能被批处理在一起，不然顺序性可能就乱套了。发送消息的时候， 记得一定要 set Key，不然 Key_Shared 就退化成 Shared 了那可就亏大了，太离谱了。。
你猜怎么着？ 再来看看 Shared 模式的配置， 有时候为了提升吞吐量，我们得把队列调大一点：
Consumer
看到那个 `maxTotalReceiverQueueSizeAcrossPartitions` 了吗？这玩意儿调大了消费者这边就能一次拿更多消息，吞吐量自然就上去了。不过也别调太大，撑爆内存可就不好玩了。
Pulsar 还有一个特别牛的功能，就是原生的多租户支持。这可是 SaaS 平台的福音啊。它通过“Tenant→ Namespace→ Topic”这三级结构，把不同客户的数据隔离开来，太治愈了。。
你想想， 以前用 Kafka，要给不同客户隔离数据，是不是得搞不同的 Cluster，或者搞不同的 Topic，还得自己写权限控制，累得要死。现在用 Pulsar，直接在配置里搞定。Tenant 是最顶层， 比如不同的业务线；Namespace 下面可以配置不同的策略，比如存储配额、保留策略；Topic 才是具体的消息通道。
这配置文件大概长这样：
说真的... pulsar: url: pulsar://192.168.8.144:6650,192.168.8.145:6650,192.168.8.146:6650 topic: topic1,topic2 # 多个 Topic 以逗号分隔 subscription: topicGroup # 消费者组名称
最终的最终。 虽然这只是个客户端配置的例子，但你能感受到那种灵活劲儿吧？多集群、多节点，随便连。
这肯定是个绕不开的话题。咱们客观一点，不吹不黑，来个简单的对比。
| 对比维度 | Pulsar | 传统 MQ |
|---|---|---|
| 架构模式 | 计算存储分离 | 计算存储耦合 |
| 存储模型 | 基于 Ledger→Segment→Entry 分层存储 | 基于 Partition 分区+副本存储 |
| 多租户支持 | 原生 Tenant+Namespace 三级隔离 | 无原生支持 |
| 消费模型 | 统一模型， 一边支持流+队列 | 单一模型 |
| 扩容能力 | 独立扩容 | 整体扩容，成本高 |
| 故障影响 | 故障隔离，影响范围小 | 存储节点故障影响计算 |
| 吞吐量 | 100 万级 QPS | 20 万级 QPS |
我惊呆了。 这表格一列出来高下立判了吧？当然Kafka 生态好，用的人多，资料多，这也是事实。但是如果你追求云原生、追求弹性、追求多租户，Pulsar 绝对是首选。而且 Pulsar 还兼容 Kafka 协议，你要是想迁移，也没那么痛苦。
虽然 Pulsar 架构好， 但是不得不说部署起来是真的有点麻烦。以前依赖 ZooKeeper + BookKeeper，组件太多了部署复杂度那是相当的高。不过现在也在搞去 ZooKeeper，把元数据存到 BookKeeper 里希望能简单点吧。
运维的时候，你得盯着 Broker，也得盯着 Bookie。Bookie 的磁盘 IO 如果跟不上，那整个集群的性能就得掉链子。而且日志与业务数据分盘存储， 读写操作互不干扰，这事儿在部署的时候就得规划好，不然到时候 IO 竞争，有你哭的，弄一下...。
还有那个死信队列和重试机制，这也是实战中经常用到的。你看这段代码：
研究研究。 Consumer consumer = .topic .subscriptionName .subscriptionType .enableRetry // 启用自动重试 .retryLetterTopic // 自定义重试主题 .deadLetterPolicy .maxRedeliverCount // 最大重试 5 次 .deadLetterTopic // 死信主题 .build) .ackTimeout .subscriptionInitialPosition // 从最早消息开始消费 .negativeAckRedeliveryDelay // 消费失败 60s 后重投 .build;
啊这... 这配置多全啊！重试几次、死信扔哪儿、Ack 超时多久，都给你安排得明明白白。这在处理业务逻辑失败的时候，简直是救命稻草。
说了这么多，Apache Pulsar 到底值不值得你花时间去学？我觉得是值得的。虽然它现在还没到统治世界的地步，但是它的架构设计确实领先一代。计算存储分离、云原生、多租户、统一的消息模型，这些都是未来的趋势。
而且，它的性能是真的强。100 万级 QPS，这可不是吹出来的。对于高吞吐、高并发的业务场景，Pulsar 简直是为之而生的，中肯。。
当然学习曲线肯定是有那么一点点陡峭。毕竟组件多，概念也多。什么 Ledger、 Entry、Segment，什么 Exclusive、Failover、Shared、 功力不足。 Key_Shared，一开始肯定得晕头转向。但是 一旦你把这些都搞明白了你会发现，构建实时消息管道、配合 Flink 做实时处理，这一切都变得那么顺畅。
所以别犹豫了赶紧去搭个集群玩玩吧。哪怕是在 Docker 上跑个单机版，也能感受到它的魅力。毕竟 技术这东西，早学早受益，别等到大家都用上了你还在那儿死磕 Kafka 的扩容问题，那可就尴尬了，PUA。。
Demand feedback
