简介Apache Pulsar 2.9.1 二进制分发压缩包面向需要在生产或测试环境部署消息中间件的后端、运维与云原生开发人员目标是省去源码编译和依赖构建解压配置后即可启动服务使用。包内包含 Pulsar 服务端可执行程序、客户端库、常用运维脚本与辅助工具整体大小约 321.53MB由于上游未提供文件清单暂不具体列举文件数量与格式。Pulsar 在 ZooKeeper 协助下管理主题、分区与集群元数据配合 BookKeeper 实现高可用、低延迟的消息持久化同时支持发布/订阅模型、共享/独占/故障转移等订阅类型并提供分层存储与 Pulsar Functions便于不常访问的历史数据迁移到低成本层也能在消息平台上直接处理流数据。其分布式与云原生架构适合接入 Kubernetes 等容器环境方便快速扩展与容错。已有 150 人学习或下载适合希望直接上手体验 Pulsar 2.9.1 核心能力的使用者。 盯上apache pulsar 2.9.1 bin.tar.gz这个包的人我猜基本是两类一类是团队正在做技术选型拿着 Pulsar 和 Kafka 来回对比需要先拉个实例跑起来看看另一类是生产环境已经定了 Pulsar要在测试环境搭一套集群做压测或者排障。不管你是哪类这个带bin.tar.gz后缀的二进制发行包都是最直接的入手点——不需要编译源码不需要折腾 Maven 或 Gradle解压就能跑。这篇文章就围绕它把版本怎么选、包怎么装、单机和集群怎么启动、踩过的坑怎么排一层层讲清楚。1. 版本选型为什么 2.9.1 值得用1.1 2.9.x 系列的历史定位Apache Pulsar 的版本节奏不算快但每个大版本之间的差异非常明显。2.9.x 这个系列在整个 Pulsar 演进里属于一个承上启下的位置它把 2.8 引入的pulsar-client新 API 稳定了下来同时对transaction功能做了大量补全2.9.1 作为 2.9 分支的修复版本重点解决了一批 broker 内存泄漏和 BookKeeper 客户端写入超时的问题。你在生产环境选版本时我个人的建议是别追最新也别停在太老的版本。2.9.1 的定位是“稳定修复版”它没有大版本的激进新特性但把 2.9.0 的坑基本都填平了。对很多只需要消息队列、延迟队列、消费订阅这些核心能力的项目来说这是一个性价比很高的选择。如果你后面要升级到 2.10 或 3.x从 2.9.1 起步的迁移路径也相对平滑不会像从 2.7 跳 3.x 那样遇到配置项大改。1.2 bin.tar.gz 和其他发行包的区别Apache Pulsar 官方在 GitHub Releases 和 Apache 镜像站上会同时提供几种包最常见的是apache-pulsar-2.9.1-bin.tar.gzapache-pulsar-2.9.1-src.tar.gz以及各连接器connector的独立压缩包bin.tar.gz的意思就是已经编译好的二进制发行包里面带着bin/、conf/、lib/、examples/这些目录。你不需要安装额外的构建工具只需要一个 JDK 环境就能启动。src.tar.gz则是最新源码需要自己用 Maven 构建还得处理依赖下载一般是为了二次开发或者定制才去碰它。我实际上下载部署过很多次强烈建议绝大多数场景直接选bin.tar.gz。它甚至不需要机器上有 Maven省掉了很多网络和依赖上的麻烦。另外如果你在公司内网部署记得提前下载好包传到目标机器因为部分网络环境直接访问 Apache 镜像站会比较慢这一点后面我会再提。2. 从下载到单机启动完整实操过程2.1 下载、校验和解压Apache Pulsar 的下载地址有官方镜像站也有 GitHub Releases 的附件。以下命令以 Linux 环境为例把2.9.1的二进制包下载到/opt并解压cd /opt wget https://archive.apache.org/dist/pulsar/pulsar-2.9.1/apache-pulsar-2.9.1-bin.tar.gz # 强烈建议校验 SHA-512 wget https://archive.apache.org/dist/pulsar/pulsar-2.9.1/apache-pulsar-2.9.1-bin.tar.gz.sha512 sha512sum -c apache-pulsar-2.9.1-bin.tar.gz.sha512 # 解压 tar -zxvf apache-pulsar-2.9.1-bin.tar.gz mv apache-pulsar-2.9.1 /opt/pulsar校验这一步很容易被忽略但这是供应链安全的第一道防线。Apache 项目发布的包都带.sha512或.asc签名你至少要做一次哈希校验确认下载过程中没有出现文件损坏或被中间人替换。我见过有人跳过校验结果解压时就报错折腾半天才发现是包不完整。解压完成后看一眼目录结构cd /opt/pulsar ls -l你会看到bin、conf、data、examples、lib、logs这几个关键目录。其中bin目录下的pulsar脚本是核心入口conf目录里放着所有配置文件包括standalone.conf、broker.conf、zookeeper.conf等。2.2 单机模式启动与验证单机模式适合开发测试和功能验证它会在一个进程里同时拉起 ZooKeeper、BookKeeper 和 Broker 三个角色。Pulsar 的 standalone 模式不需要你做任何额外配置直接执行cd /opt/pulsar bin/pulsar standalone首次启动会初始化元数据然后监听8080HTTP 服务端口和6650客户端通信端口。看到日志里出现pulsar-service started或者类似信息说明启动成功。接着我们可以通过命令行工具验证一下# 创建名为 my-topic 的 topic bin/pulsar-admin topics create persistent://public/default/my-topic # 生产一条消息 bin/pulsar-client produce my-topic --messages hello-pulsar-2.9.1 # 消费这条消息 bin/pulsar-client consume my-topic --subscription-name my-sub --num-messages 1如果你能在消费端看到hello-pulsar-2.9.1整个链路就通了。这里特别注意pulsar-client consume默认会一直阻塞等待新消息加--num-messages 1可以只消费一条后退出适合测试。2.3 Java 环境和内存要求Pulsar 2.9.1 官方要求 Java 8 或 11我实际用下来 JDK 11 的稳定性最好。确认方式java -version如果机器上有多套 JDK务必确认默认java命令指向的版本。Pulsar 启动脚本默认读取JAVA_HOME环境变量如果设置不对会直接抛UnsupportedClassVersionError。内存方面standalone 模式默认的堆内存配置不算大但如果你的机器内存少于 4G建议修改conf/pulsar_env.sh里的PULSAR_MEM配置防止 BookKeeper 和 broker 抢内存导致操作系统 OOM。我通常这样设置PULSAR_MEM-Xms512m -Xmx1g -XX:MaxDirectMemorySize1g需要说明的是这只是微调不要贸然把堆内存调到物理内存以上否则系统 Swap 会拖垮性能。3. 从单机走向集群部署经验和配置避坑3.1 最小集群的角色划分生产环境很少用 standalone通常至少需要三个角色独立部署ZooKeeper、BookKeeper、Broker。有些团队还会把 BookKeeper 分出一组专用于 system topic 的节点但对起步阶段来说一个最小集群可以由 3 台机器组成每台机器同时跑一个 ZooKeeper、一个 BookKeeper、一个 Broker这是比较省机器的方案。如果资源允许我建议 ZooKeeper 单独 3 台BookKeeper 和 Broker 混合部署因为 ZooKeeper 节点对磁盘 IO 的抖动很敏感。3.2 关键配置项在conf/broker.conf里最重要的几个配置是zookeeperServerszk1:2181,zk2:2181,zk3:2181 configurationStoreServerszk1:2184,zk2:2184,zk3:2184 advertisedAddressbroker-ip bindAddress0.0.0.0advertisedAddress一定要填客户端能够访问到的地址很多部署问题都是因为这里填成了localhost或者内网 DNS 无法解析的主机名导致客户端连接 broker 失败。BookKeeper 的配置在conf/bookkeeper.conf关键项是zkServerszk1:2181,zk2:2181,zk3:2181 journalDirectory/data/pulsar/bookkeeper/journal ledgerDirectories/data/pulsar/bookkeeper/ledgers这里我强烈建议把journalDirectory和ledgerDirectories放到数据盘不要放系统盘。BookKeeper 的 journal 是同步写盘对磁盘延迟非常敏感用 SSD 和机械盘跑出来的写入性能相差很大。我踩过这个坑一开始图省事把数据放在默认目录结果 Topic 数量一多IO 等待直接飙高broker 日志里全是 Bookie 写入超时。集群启动顺序也有讲究必须先 ZooKeeper再 BookKeeper最后 Broker。反过来启动Broker 会因为找不到 ZooKeeper 而反复重试日志刷屏不说恢复时间也会被拖长。3.3 用 systemd 管理 Pulsar 进程手动用bin/pulsar启动进程SSH 一断服务就没了不适合生产。我一般会写 systemd unit 文件来托管。拿 Broker 举例[Unit] DescriptionApache Pulsar Broker Afternetwork.target zookeeper.service bookkeeper.service [Service] Typesimple Userpulsar EnvironmentJAVA_HOME/usr/lib/jvm/java-11-openjdk ExecStart/opt/pulsar/bin/pulsar broker Restarton-failure RestartSec10 LimitNOFILE65536 [Install] WantedBymulti-user.target把这个文件放在/etc/systemd/system/pulsar-broker.service然后执行systemctl daemon-reload systemctl enable pulsar-broker systemctl start pulsar-brokerLimitNOFILE65536这一项经常被忽略。Pulsar 作为消息系统会打开大量 socket 和文件句柄系统默认的 1024 限制会在高连接数时直接导致服务崩溃。4. 常见问题与排查技巧实录4.1 端口被占用导致启动失败Pulsar 启动时报Address already in use最典型的是8080或者6650被占用。排查方式ss -lntp | grep 8080如果确认是旧进程残留直接 kill 后重启。还有种隐蔽情况多个 Pulsar 实例共用一台机器一个配置里漏改了监听端口两个进程就会冲突。我在测试环境经常同时起多个 standalone每次都记得改conf/standalone.conf里的webServicePort和brokerServicePort。4.2 客户端连不上 broker客户端连不上时不要第一时间怀疑防火墙先把 broker 日志拉出来看一眼。常见原因有三个advertisedAddress配置错误客户端拿到的是 broker 内部地址连不通。客户端网络到 broker 的6650端口被防火墙或安全组拦截。Broker 处于 starting 状态还没有完成初始化客户端连接直接被拒绝。第三种情况最容易误导人因为进程明明在端口也监听着但 broker 内部的 namespace 初始化没完成。看日志会发现类似There is no topic policy或者Failed to load namespace报错等 10-20 秒再重试就好。4.3 Pulsar 和 Kafka到底谁资料更丰富选型阶段很多人会纠结这个问题。老实说Pulsar 的中文资料数量确实不如 Kafka 多Kafka 入华早社区沉淀了大量文章和博客。但 Pulsar 的官方文档完整度很高Apache Pulsar 的官方站点、GitHub 仓库、邮件列表以及 StreamNative 的中文社区文档都能找到足够上手的资料。从我实操的感受来看Pulsar 的架构设计比 Kafka 更复杂学习曲线陡一些但官方提供的pulsar-admin、pulsar-client命令行工具使用起来非常顺手很多管理操作不需要额外开发代码。资料少不是主要障碍难的是你对底层 BookKeeper 的认知这块需要多读官方文档。5. 深入解读 Message ID为什么是messageid|28077:20854:05.1 Ledger ID 和 Entry IDPulsar 消息的唯一坐标有朋友看到messageid|28077:20854:0这种格式会困惑这串数字到底怎么来的。其实 Pulsar 的消息 ID 由三部分组成ledgerId:entryId:partitionIndex部分场景还会带上batchIndex但 API 层面最常见的就是这三个字段。在 Pulsar 的底层存储里数据按 Ledger分段组织一个 Ledger 是一个连续的 Entry 序列。每条消息写入时都会被分配一个(ledgerId, entryId)二元组作为物理位置。拿28077:20854:0来说28077是 ledger ID20854是 entry ID最后一个0表示这条消息来自主题的 0 号分区。第一个28077前面的messageid|只是客户端打印时方便识别的前缀不是 ID 的一部分。这也解释了为什么 Pulsar 的 Offset 不像 Kafka 那样是一个单调递增的整数而是一个“坐标”。由于消息分布在不同 Ledger 里你不能简单用一个大数去描述“消费位置”。5.2 与 Kafka Offset 的对比Kafka 的消息位置就是 partition 内的一个长整型 offset消费者保存的是“下一个要消费的位置”实现起来很直观。Pulsar 用(ledgerId, entryId)来表示位置好处是存储层天然支持 Ledger 级别的数据管理和恢复坏处是如果你想在代码里比较两个 Message ID 的大小不能直接比长整型要写msgId.compareTo(anotherMsgId)。好在官方 Java 客户端已经封装好了你只要用MessageId接口不需要自己解析字符串。5.3 看 Message ID 能发现什么排查消息积压或者消费卡住时Message ID 非常有用。客户端日志里会打印当前消费到的位置如果你发现 ID 长时间不变说明消费端已经停止拉取。而ledgerId增长幅度很大时说明系统在持续产生数据broker 不断创建新的 ledger。如果想知道某条消息到底从哪来还可以用pulsar-admin topics peek-messages工具直接查看指定位置的原始消息内容。bin/pulsar-admin topics peek-messages \ --topic persistent://public/default/my-topic \ --subscription my-sub --count 1这个命令会把消息体、消息 ID 和 publish time 一起打出来排查时非常有价值。6. 部署后的日常维护建议最后分享几条我在实际操作中提炼出来的维护经验。Pulsar 2.9.1 不是那种解压缩就一劳永逸的系统它的日常健康检查至少要关注三块ZooKeeper 的节点状态、BookKeeper 的磁盘使用率、Broker 的 GC 情况。BookKeeper 的磁盘容量是第一个容易爆的。Pulsar 的消息数据默认不会自动过期如果没有设置 topic 的retention策略磁盘会被持续占满。建议上线前就规划好 retention 和 ttl用pulsar-admin namespaces set-retention给 namespace 设置大小或时间上限。GC 方面观察 broker 进程的堆内存使用曲线如果老年代持续增长且回收不掉优先怀疑是否有消费者长期不提交 ack导致 broker 积压了太多未确认消息。管理端可以用pulsar-admin topics stats查看订阅积压情况bin/pulsar-admin topics stats persistent://public/default/my-topic重点关注msgBacklog和blockedSubscriptionOnUnackedMessages这两个字段如果积压持续上涨就要去排查消费者逻辑了。2.9.1 是我个人用下来比较顺手的版本它在稳定性和新特性之间找到了一个平衡点。部署这事照着上面这些步骤来单机验证半天内能跑通集群配上 systemd 加监控基本可以安心交给运维。后面如果因为业务需求要到 3.x再把配置迁移和新特性吃透那是另一个话题了。本文还有配套的精品资源点击获取