简介Apache Pulsar 2.9.1 二进制发行包面向需要部署分布式消息队列的架构师、开发与运维人员提供开箱即用的服务端、客户端及脚本工具。该版本深度融合 ZooKeeper 进行元数据协调同时依托 BookKeeper 实现高可用、低延迟的消息持久化并支持分层存储与 Pulsar Functions 轻量流处理适用于云原生环境下的实时数据管道、微服务通信等场景。压缩包大小约 321.53 MB内部包含完整的 bin 目录与配置模板便于快速搭建集群并体验多租户、多订阅模式等核心特性。目前已有 150 人学习下载。对希望降低消息中间件运维成本、构建高吞吐可靠消息系统的团队而言这份二进制包能显著缩短环境准备时间直接进入功能性验证与二次开发阶段。Apache Pulsar 2.9.1 部署实践从 bin.tar.gz 到可用的消息流平台这几年做消息中间件选型和运维Kafka 和 RabbitMQ 玩得比较多Pulsar 属于那种“早就听说很强但一直没上手”的类型。直到有个项目需要同时应对高并发写入和多租户隔离才真正把 Apache Pulsar 提上日程。这次我选择的是 2.9.1 版本的二进制发行包也就是标题里的apache pulsar 2.9.1 bin.tar.gz。这篇博文就把我这次的部署过程、踩过的坑、以及这个版本的一些特性心得完整记录下来希望能帮你少走弯路。Pulsar 和传统消息队列最大的区别在于架构它把存储和服务分离底层用 BookKeeper 存数据上层提供 Broker 服务。这就让它天然支持多租户、跨地域复制和分层存储而且扩容的时候不需要数据搬迁。2.9.1 这个版本虽然不是最新的但胜在稳定社区反馈的坑也基本被填平了适合作为生产环境的起步版本。这篇文章适合刚接触 Pulsar 的运维同学、准备做消息中间件选型的架构师以及想快速搭一套本地环境跑通的开发者。1. 为什么选择 bin.tar.gz 而不是源码包1.1 bin.tar.gz 与源码包的本质区别Apache Pulsar 官方提供了两种发布物apache-pulsar-2.9.1-src.tar.gz和apache-pulsar-2.9.1-bin.tar.gz。很多人第一次下载时容易混淆其实区别非常简单源码包需要你自己装 Maven、JDK然后执行mvn clean install编译整个构建过程少说要二三十分钟而且还会下载一大堆依赖网络不好直接劝退。而bin.tar.gz是官方已经编译好的可运行版本解压后修改一下配置文件就能直接启动 Broker、BookKeeper 和 Zookeeper。我选择二进制包还有一个原因Pulsar 本身是用 Java 写的编译过程涉及大量的依赖解析和模块构建如果只是想验证功能或者部署生产环境没必要从源码开始折腾。官方在发布二进制包时已经做了充分的兼容性测试直接用就好。提示如果你的项目需要对 Pulsar 源码做二次开发那才需要下载 src 包否则一律建议 bin 包节省时间也降低出错概率。1.2 2.9.1 版本的核心特性盘点2.9.1 是 2.9.0 的补丁版本修复了一些已知问题同时保留了 2.9 系列的主要特性。这个版本最吸引我的几点是分层存储支持将旧数据卸载到 S3 或 HDFSBroker 本地只保留热数据冷数据走分层存储这在降低存储成本上非常有用。我之前那套 Kafka 集群磁盘满了只能加节点Pulsar 这种方式明显更灵活。多租户Pulsar 在 Broker 层面就内置了多租户支持一个集群里可以划分多个租户tenant每个租户下面再分命名空间namespace通过权限控制实现资源隔离。对于需要给多个业务线提供消息服务的场景这个能力非常实用。Function 轻量化计算Pulsar Functions 允许你直接在消息流上写简单的处理逻辑类似 Flink 的简化版很多简单的 ETL 场景不用再单独引入流处理框架。协议兼容2.9.x 系列支持 Kafka 协议接入也就是说你可以用 Kafka 的客户端去连接 Pulsar。这个功能在迁移场景下特别重要不需要改动业务代码就能把流量切过来。Broker、BookKeeper、Zookeeper 三种角色都集成在同一个包内部署模式非常灵活。测试环境可以用 Standalone 模式一键启动生产环境则可以拆开分别部署每个组件独立扩容。2. 部署前必读目录结构、配置与资源规划2.1 解压后目录结构逐层拆解拿到apache-pulsar-2.9.1-bin.tar.gz后先别急着启动花几分钟看看目录结构后面排查问题会轻松很多。解压后你会看到一个apache-pulsar-2.9.1目录里面有这些关键路径bin/存放所有可执行脚本比如pulsar、pulsar-admin、pulsar-client日常操作基本都靠这几个命令。conf/配置文件目录最重要是broker.conf、standalone.conf、zookeeper.conf和bookkeeper.conf。lib/Pulsar 运行依赖的所有 Jar 包不用动它。logs/默认日志输出目录启动后查看运行状态和报错信息都在这。data/BookKeeper 和 Zookeeper 的数据存储目录首次启动后自动生成。examples/官方提供的示例包括 Java、Python 和 Go 的客户端代码快速验证功能时可以直接参考。看清这些目录之后你对整个系统的运行方式就有了基本概念。后面做权限管控、日志清理、数据备份时也都围绕这些目录展开。2.2 关键配置项与 JVM 调优建议配置方面不同部署模式对应不同的配置文件。如果你是第一次跑建议先用conf/standalone.conf熟悉基本参数因为我实际踩过不少配置项的坑这里展开几个最关键的brokerServicePort和webServicePort分别是 Broker 的服务端口默认 6650和 HTTP 管理端口默认 8080。如果端口被占用服务会启动失败而且日志里报错不明显容易让人误判是依赖组件出了问题。zookeeperServers指向 Zookeeper 地址多机部署时用逗号分隔。Standalone 模式下默认是本地 2181 端口。configurationStoreServersPulsar 的元数据存储同样使用 Zookeeper。生产环境通常会和zookeeperServers指向同一个 Zookeeper 集群。managedLedgerDefaultEnsembleSize、managedLedgerDefaultWriteQuorum、managedLedgerDefaultAckQuorum这三个参数控制 BookKeeper 的副本策略分别对应存储节点数、写入副本数、确认副本数。单机测试保持默认即可生产环境至少设为 3/3/2。JVM 调优方面Pulsar 默认的堆内存配置在conf/pulsar_env.sh里。因为 Broker 和 BookKeeper 在同一个进程内运行时对内存需求差异较大我的经验是如果 Broker 和 BookKeeper 混部需要适当调大PULSAR_MEM否则高负载下容易出现频繁 Full GC 甚至 OOM。可以用下面的配置做基准PULSAR_MEM-Xms2g -Xmx4g -XX:MaxDirectMemorySize4g这个值需要根据机器实际内存调整因为 BookKeeper 大量使用堆外内存DirectMemory如果只调堆内存而忽略 DirectMemory还是会出问题的。注意修改pulsar_env.sh后记得重启 Pulsar 进程动态修改不生效。另外不要在生产环境强行使用/bin/pulsar standalone这种方式它只是为了测试方便。3. 从下载到运行Pulsar Standalone 完整实操3.1 下载、校验与解压第一步是去 Apache 官网下载对应的二进制包。建议去官方下载页面选择清华镜像或者你所在区域的镜像速度会比官网快很多。这里强调一个细节下载后要校验 SHA512 校验码因为 Apache 官方对发布物的完整性校验非常重视。具体做法是wget https://archive.apache.org/dist/pulsar/pulsar-2.9.1/apache-pulsar-2.9.1-bin.tar.gz echo 下载页面的sha512值 apache-pulsar-2.9.1-bin.tar.gz | sha512sum -c -校验通过后解压tar -zxvf apache-pulsar-2.9.1-bin.tar.gz cd apache-pulsar-2.9.1解压后确认 JDK 版本Pulsar 2.9.1 要求 JDK 8 或 JDK 11。我之前在 JDK 17 上尝试启动过结果直接报错所以这里建议先用java -version确认一下免得后面反复折腾。3.2 单机模式启动与功能验证Standalone 模式是 Pulsar 提供的单机运行方式它会自动在后台启动一个 Zookeeper、一个 BookKeeper 和一个 Broker全部都在同一台机器上。这个模式适合开发调试也是我第一次接触 Pulsar 时用的方式。启动命令很简单bin/pulsar standalone敲完这个命令后不要急着关掉终端因为日志会直接滚动输出到控制台。看到类似PulsarStandalone started successfully的日志就说明启动成功了。我习惯再开一个窗口用命令验证端口监听状态ss -lntp | grep -E 6650|8080如果看到 8080Web 服务和 6650消息服务端口都在监听说明核心组件全部正常启动。接下来用官方自带的生产者消费者示例验证一下消息收发是否正常。打开两个终端一个执行bin/pulsar-client produce -m hello pulsar test-topic另一个执行bin/pulsar-client consume -s my-subscription -n 10 test-topic如果消费者能收到hello pulsar这条消息说明整个链路已经通了。这一步非常关键因为很多部署问题要等到真正收发消息时才会暴露出来单纯看到进程启动成功并不代表一切正常。3.3 通过 REST API 和命令行确认服务健康除了收发消息我还会用pulsar-admin检查集群健康状态。这个工具是后续日常运维用的最多的命令必须熟练。几个我常用的验证命令bin/pulsar-admin clusters list这条命令会返回集群列表Standalone 模式下默认是standalone。还可以查看租户和命名空间bin/pulsar-admin tenants list bin/pulsar-admin namespaces list public/default如果这几条都能正常返回数据说明元数据存储、Broker 和 BookKeeper 之间的通信都是通的。当然也可以直接通过 HTTP 接口验证浏览器里访问http://localhost:8080/admin/v2/clusters如果返回 JSON 数组说明 Web 层也正常。这里的注意点是REST API 的/admin/v2路径和旧版的/admin路径有区别2.9.x 版本已经全面走 v2 了查询文档时需要注意版本匹配。4. 常见问题与排查技巧实录4.1 启动失败与端口冲突实际操作中遇到的问题最普遍的就是启动失败。分布式系统组件多一个端口被占用整个服务就起不来。我之前遇到过一次 8080 端口被一个监控 agent 占用的场景报错日志隐藏在 Broker 启动流程中段如果不仔细看很容易忽略而且当时的报错没有直接说“port in use”而是抛了一堆莫名的连接异常排查了很半天。在这之后我每次启动前都会固定执行一次端口检查ss -lntp | grep 8080 ss -lntp | grep 6650 ss -lntp | grep 2181如果没有输出说明端口空闲可以继续启动。另外Zookeeper 的 2181 端口也很关键如果上一个没删干净的 Pulsar 进程还占据着端口也会启动失败。建议在启动前先ps -ef | grep pulsar确认没有残留进程。4.2 BookKeeper 元数据初始化问题另一个容易踩的坑是 BookKeeper 的元数据初始化。第一次启动时Pulsar 会在 Zookeeper 中自动创建 BookKeeper 相关的元数据节点。如果这个过程失败BookKeeper 就无法正常注册 Ledger 信息客户端生产消息时会报Bookkeeper journal manager not started之类的错误。这种情况多半是因为 Zookeeper 地址配置不对或者 Zookeeper 本身没起来。在 Standalone 模式下Pulsar 会自动拉起 Zookeeper但如果你的机器上已经有一个 Zookeeper 在监听 2181Pulsar 不会去检查它是不是自己创建的而是直接尝试复用此时容易产生兼容性问题。提示如果在生产环境准备把 Zookeeper 和 Broker 分开部署务必先初始化 BookKeeper 元数据。官方文档提供了初始化命令bin/bookkeeper shell metaformat -nonInteractive。如果没做这一步就启动 Broker服务能起来但客户端连不上存储层此时排查起来非常折腾。我自己在测试集群上就遇到过类似问题因为之前清理不干净Zookeeper 里残留了旧的 BookKeeper 元数据导致新集群起不来。解决办法是停掉所有组件后清理数据和日志目录再重置 Zookeeper 元数据最后重新启动。注意清理数据是高风险操作生产环境千万别直接删要先备份。4.3 生产环境部署建议通过 Standalone 模式跑通之后如果要上生产有几点要提醒自己也分享给大家一是部署模式上Zookeeper、BookKeeper、Broker 这三个角色要分开。Pulsar 的优势之一就是各个组件可以独立扩缩容。如果业务增长快Broker 和 BookKeeper 的扩容策略完全不一样Broker 是无状态的前面挂负载均衡就行BookKeeper 则要关注磁盘和 IO 吞吐扩的时候要注意副本策略与节点数匹配否则可能出现写入热点。二是 JVM 和系统参数需要提前调优。包括文件描述符限制ulimit -nPulsar 是个高并发网络服务默认 1024 的限制肯定不够建议至少调到 65535 以上。还有内存参数要根据业务消息量提前估算避免运行一段时间后出现 OOM。三是消息保留策略。Pulsar 默认会持久化所有消息不会自动清理。如果不配置 TTL 或保留策略时间一长磁盘就会暴涨。我之前就见过有人 Pulsar 跑了一个月磁盘报警发现是消息保留策略没有设置。2.9.1 版本可以通过pulsar-admin namespaces set-retention给某个命名空间设置保留时间和大小上限建议上线前就配置好。四是监控系统要提前接好。Pulsar 提供了 Prometheus 指标暴露接口默认是http://localhost:8080/metrics。把这些指标接入 Grafana配合官方提供的 Pulsar dashboard 模板可以清晰地看到 Broker 负载、BookKeeper 写入延迟、Topic 流量等关键信息。等到出了故障再想加监控往往已经来不及了。5. Pulsar 与 Kafka消息队列选型的一些思考标题的热搜词里有一条是“pulsar 和 kafka 哪个资料丰富一些”这其实代表了很多人对 Pulsar 的顾虑。说实话Kafka 进入大众视野早生态确实成熟中文资料也明显更多。但 Pulsar 在架构层面解决的问题Kafka 到现在也没有完全跟上。Kafka 的存储模型是分区日志Broker 和存储强绑定分区迁移时要拷贝大量数据而且分区数量一旦上去Broker 的负担会比较重。Pulsar 使用 BookKeeper 作为存储层数据和服务是解耦的扩容时不需要数据搬迁。另外 Pulsar 在消息消费模型上支持共享订阅和键值订阅这比 Kafka 只用消费组实现要灵活得多。Pulsar 的 MessageId 形式是messageId|28077:20854:0第一次看到确实让人发懵。这其实是 LedgerId:EntryId 的组合分别对应 BookKeeper 中的 Ledger 编号和 Entry 编号。理解了这个结构你在排查消息堆积或者数据不一致问题时就能快速定位到数据块所在的位置而不只是一个简单的偏移量。这种设计带来了一些学习成本但它的好处是消息的物理存储位置是确定的做数据恢复和审计时有据可循。所以我的建议是如果你的团队已经深度绑定 Kafka 且业务运行稳定没必要强行迁移如果是从零搭建消息平台并且对多租户、跨地域复制、分层存储有明确需求Pulsar 值得优先考虑。最后再分享一个小技巧当前官方下载页面提供的版本可能比较新但老版本依然可以在 Apache Archive 站点找到。2.9.1 这个版本我已经在多个环境上验证过稳定性不比最新版差。如果你也在做消息平台的选型或迁移可以先从bin.tar.gz包开始花一个小时按上面的流程把 Standalone 跑通再决定要不要深入。这个版本带来的架构理念升级绝对值得你花时间了解。本文还有配套的精品资源点击获取