简介Apache Pulsar 2.9.1 二进制发行包面向分布式消息中间件开发者、运维人员及云原生平台学习者用于快速获取可部署的 Pulsar 服务端与客户端相关组件围绕发布/订阅、消息持久化和集群协调开展实验与架构验证。压缩包约321.53MB文件总数上游标注为0、主要文件类型明细暂未提供按发行包定位内容主要承载运行时二进制、辅助脚本及相关库文件。已有152人学习说明其在 Pulsar 入门与版本留存方面具有一定参考价值。资源可帮助读者结合 ZooKeeper 元数据协调、BookKeeper 持久化、共享/独占/故障转移订阅、分层存储与 Pulsar Functions 等知识点搭建本地或云原生环境进行功能对照和方案验证适合作为 2.9.1 版本的学习与实验包。1. 解压完就敲bin/pulsar standalone的多半会遇到一次“假成功”有台测试机上放了个apache-pulsar-2.9.1-bin.tar.gz同事解压到/opt直接bin/pulsar standalone日志刷了几屏停在“messaging service is ready”看着成了。第二天另一个节点上的客户端连 6650 一直超时8080 也打不开——这套在云原生环境里被讲得很多的分布式消息系统装起来最不缺就是这种“假成功”。2.9.1 是个挺典型的分界版本ZooKeeper 已经坐实成集群元数据的唯一来源broker 靠bookkeeperMetadataServiceUri去找 ledgerclusterName少写一个字、advertisedAddress回落成 127.0.0.1本机跑得好好的服务换台机器就变哑巴。这里按我实际装机的顺序走一遍钉死 JDK 和内核参数解压改conf/分 standalone 和伪集群两条路启动最后用一串命令验证到端到端收发。第一次在这台机器上落 Pulsar 2.9.1 的人或者装过一次但没搞清 ZooKeeper、BookKeeper、broker 三层关系的都能照着走。2. 环境预热JDK 版本、文件句柄和四个必查端口我习惯在解压之前把机器先摸一遍。这一步花不了十分钟但能挡掉后面八成的玄学问题——尤其是 JDK 和句柄这两项出问题的时候日志指向都不明显新手容易被带到别处去查。2.1 JDK 选 8 还是 11Java 17 上会怎么失败Pulsar 2.9.1 这一代支持 JDK 8 和 JDK 11实际用下来 11 更稳GC 表现和后续版本衔接都顺。真正容易出问题的是 Java 17 及以上Netty 和 BookKeeper 里一堆反射调用在模块化之后被挡掉进程起不到十秒就抛InaccessibleObjectException或者干脆UnsupportedClassVersionError。如果机器上已经有 17又没有把JAVA_HOME显式指到 11bin/pulsar脚本会默默用 PATH 里那个 java你会以为是安装包的问题。先把现状查清楚# 看默认 java 是哪个版本、真实路径指向哪里 java -version 21 echo JAVA_HOME${JAVA_HOME} readlink -f $(which java) # 机器上装了哪些 JDKRPM 系 / DEB 系各一条 rpm -qa | grep -i openjdk ls -1 /usr/lib/jvm 2/dev/null第一条命令输出里的版本号要落在1.8.0_xxx或11.0.xJAVA_HOME为空说明脚本会走 PATH多 JDK 机器上这是最常见的错配来源readlink那条是看软链接最终指向/etc/alternatives/java这种中介层很容易让人误判。没有 11 的话装一个两个发行系都给出来# RHEL / CentOS 系 sudo yum install -y java-11-openjdk-devel # Debian / Ubuntu 系 sudo apt update sudo apt install -y openjdk-11-jdk装完在 Pulsar 的运行用户下把JAVA_HOME定死别只写进 root 的 profile——服务用哪个账户跑就在哪个账户的~/.bashrc或者/etc/profile.d/pulsar.sh里写# /etc/profile.d/pulsar.sh export JAVA_HOME/usr/lib/jvm/java-11-openjdk export PATH$JAVA_HOME/bin:$PATH提示/usr/lib/jvm/下的目录名各发行版不一样java-11-openjdk、java-11-openjdk-amd64、java-11-openjdk-11.0.x都见过写之前先ls一眼。如果因为别的组件必须留在 17 上理论上可以在conf/pulsar_env.sh里补--add-opens java.base/java.langALL-UNNAMED这类参数把它凑合起来但我试过的几次都不太干净BookKeeper 的 DbLedgerStorage 仍有概率在半路报错。与其在--add-opens上耗时间不如给 Pulsar 单独准备一个 11 的运行时代价低得多。2.2 文件句柄和内核参数不改会在压测时崩Pulsar 每个 ledger 都要开文件bookie 侧尤其密集。默认ulimit -n一般是 1024standalone 跑到几百个 topic 就开始报Too many open files而且报错位置在 Netty 的 acceptor 线程里看起来跟文件毫无关系第一次见很难往这里想。官方建议值是 65536 起。查当前值ulimit -n ulimit -u改法分两种。走 shell 会话的写 limits 配置# /etc/security/limits.d/pulsar.conf pulsar soft nofile 65536 pulsar hard nofile 131072 pulsar soft nproc 32768 pulsar hard nproc 32768nofile是打开文件数nproc是进程/线程数Pulsar 的线程模型比较吃后者一起放开省事。改完重新登录该用户才生效ulimit -n再查一次。走 systemd 托管的limits.d 是不生效的得在 unit 文件里写# /etc/systemd/system/pulsar.service 片段 [Service] Userpulsar LimitNOFILE131072 LimitNPROC32768顺带把 swap 调低。bookie 对延迟敏感一旦被换到 swap 上写 journal 的耗时能翻几十倍表现出来就是“集群没报错但是特别慢”# 临时生效 sudo sysctl -w vm.swappiness1 # 持久化 echo vm.swappiness1 | sudo tee /etc/sysctl.d/99-pulsar.conf sudo sysctl -p /etc/sysctl.d/99-pulsar.confvm.swappiness1表示非到万不得已不用 swap比设 0 温和一些避免某些内核版本上 OOM killer 行为过激。这一项对单机测试影响不大但只要不是纯玩具环境建议一开始就设上后面省得回头查。2.3 端口占用standalone 一次要占四个Pulsar 2.9.1 单机跑起来会同时监听几个端口装机前先扫一遍能避免“启动成功但实际连到了别的服务上”这种更隐蔽的问题端口作用出现场景2181ZooKeeper 客户端端口standalone、伪集群都有3181Bookie 的 bookiePortstandalone、伪集群都有6650Broker 二进制协议端口客户端连这个8080Broker HTTP / Admin API控制台、pulsar-admin走这个扫端口# 看这几个端口有没有被占以及占的是谁 ss -lntp | grep -E :(2181|3181|6650|8080)\b输出为空最省心。如果 2181 被人占了先别急着改 Pulsar 的配置——很可能是机器上已经跑着一个独立的 ZooKeeper 给别的组件用。这种情况要么换端口要么干脆让 Pulsar 复用那个 ZooKeeper前提是它版本在 3.5 以上并且你能接受共用一个根节点。我一般倾向于给 Pulsar 单独一个 ZK省得后面 chroot 路径打架。真的需要换端口改的位置分散在三份配置里ZK 的在conf/zookeeper.conf的clientPortbookie 的在conf/bookkeeper.conf的bookiePortbroker 的在conf/broker.conf的brokerServicePort和webServicePort。standalone 模式下这些都被conf/standalone.conf揉在一起了改那一份即可。3. 落地部署解压路径、conf 分工与数据目录安装包落地这一步看着最没技术含量实际上路径选错、目录权限给错、数据目录留在默认位置是后面重装和升级时最容易反复出问题的地方。我踩过一次把data/留在/tmp下的坑机器重启后目录被清broker 起来发现 ledger 全丢愣了半天才反应过来。所以这一章的核心是把“装在哪、谁管哪份配置、数据放哪”这三件事一次定死。3.1 解压位置、专用用户和软链接不要用 root 跑 Pulsar也不要解压到家目录。我固定用/opt/pulsar作为父目录解压出带版本号的真实目录再用一个current软链接指过去。这样升级 2.9.1 到更高版本时只需要改软链接conf/和数据目录都可以留在外面。# 建专用用户和父目录 sudo useradd -r -m -s /bin/bash pulsar sudo mkdir -p /opt/pulsar # 解压到父目录会生成 apache-pulsar-2.9.1 sudo tar -xzf apache-pulsar-2.9.1-bin.tar.gz -C /opt/pulsar # 软链接指向当前版本 sudo ln -sfn /opt/pulsar/apache-pulsar-2.9.1 /opt/pulsar/current # 把运行目录交给 pulsar 用户 sudo chown -R pulsar:pulsar /opt/pulsartar -xzf ... -C里的-C是指定解压目标目录不加的话会解到当前工作目录别人在别的路径下敲同一条命令就解到别处去了。软链接用-sfn三个参数-s建软链、-f覆盖已存在的、-n防止目标是目录软链时被当成目录钻进去——第三条不加重装时会得到一个current/apache-pulsar-2.9.1的嵌套结构。解压后先确认目录结构ls -1 /opt/pulsar/current # bin conf examples lib licensesbin/是所有启动脚本conf/是配置lib/是依赖 jar。lib/下的 jar 数量决定启动时要加载多少类第一次启动慢一些是正常的别以为卡死了就 Ctrl-C。3.2 conf 目录里谁管谁conf/下文件不少第一次看容易懵。按角色记就清楚了文件管谁什么时候动pulsar_env.shJVM 内存、GC、额外-D参数每个角色都会读必改broker.confbroker 侧全部配置伪集群必改bookkeeper.confbookie 侧配置伪集群必改zookeeper.confZooKeeper 侧配置一般只改端口和数据目录standalone.conf把上面三份揉在一起只跑 standalone 时改这份proxy.conf、functions-worker.conf代理、函数计算这一轮不碰先说pulsar_env.sh它是所有脚本共用的环境变量入口bin/pulsar、bin/pulsar-daemon、bin/bookkeeper都会 source 它。默认给的内存比较保守单机跑 standalone 会明显不够用改法# conf/pulsar_env.sh 关键几行 # 堆内存和堆外内存按机器内存的 1/4 ~ 1/2 给 export PULSAR_MEM-Xms2g -Xmx2g -XX:MaxDirectMemorySize4g # 额外 JVM 参数OOM 时直接退出别让进程半死不活 export PULSAR_EXTRA_OPTS-Dpulsar.allocator.exit_on_oomtrue-Xms和-Xmx设成一样大省掉运行时扩堆带来的抖动。MaxDirectMemorySize这条是重点Pulsar 收发消息走 Netty 的堆外内存这个值给太小会在流量上来之后抛OutOfDirectMemoryError而且报错栈里全是 Netty 的类名很容易误判成网络问题。经验上它至少是堆的 1.5 到 2 倍8G 内存的测试机给 4g 比较从容。pulsar.allocator.exit_on_oomtrue的意思是堆外内存分配失败就退出进程交给外部拉起。不加这个进程会进入一种“还活着但不干活”的状态监控上还能看到端口在听实际请求全超时——这是最难查的一类现场。注意conf/里可能还有pulsar_env.sh的.example或者发行版提供的模板改之前确认自己改的是脚本真正 source 的那一份。3.3 数据目录journal 和 ledger 别放同一块盘bookie 有两类写journal是顺序追加的预写日志ledger是随机读写的实际存储。放同一块盘上会互相抢 IO本地测试无所谓稍微有点量就能看出延迟抖动。我的做法是统一放/data/pulsar下分三个子目录先保证不落在解压目录里机器重启、重装、换版本都不会牵连到数据。# 建数据目录并交给 pulsar 用户 sudo mkdir -p /data/pulsar/{journal,ledger,indexes,zookeeper} sudo chown -R pulsar:pulsar /data/pulsar对应改conf/bookkeeper.conf# conf/bookkeeper.conf 关键几行 # bookie 对外的地址别留空留空会拿主机名跨机访问容易解析不到 advertisedAddress127.0.0.1 bookiePort3181 # 三类数据分开存放 journalDirectory/data/pulsar/journal ledgerDirectories/data/pulsar/ledger indexDirectories/data/pulsar/indexes # 用 DbLedgerStorage2.9 里的默认选择索引和 ledger 分离 ledgerStorageClassorg.apache.bookkeeper.bookie.storage.ldb.DbLedgerStorage # 元数据存储位置2.9 用 URI 形式不再是老的几行 servers 配置 metadataServiceUrizkhierarchical://127.0.0.1:2181/ledgersjournalDirectory和ledgerDirectories分别对应顺序写和随机写测试机上可以同盘不同目录生产环境分盘。metadataServiceUri这行是 2.9 的一个明显变化以前是zkServers加一堆零散配置现在统一成 URIzkhierarchical表示用分层命名空间后面的/ledgers是 BookKeeper 在 ZK 里的根路径这个路径一旦写下去就不能随便改改了等于让 bookie 去一个空目录里找元数据表现是启动时提示未格式化。ZooKeeper那边对应改conf/zookeeper.conf# conf/zookeeper.conf dataDir/data/pulsar/zookeeper clientPort2181 # 3.5 之后四字命令默认被白名单挡住排查时要用的几个显式放开 4lw.commands.whitelistsrvr,stat,ruok,mntr最后一行属于典型的踩坑后才知道的配置。ZooKeeper 3.5 以后出于安全考虑把ruok、stat这些四字命令默认关了而排查 Pulsar 集群时最常用的恰恰是echo ruok | nc 127.0.0.1 2181。不放开白名单命令直接返回空你会以为 ZK 挂了其实它活得好好的。4. 两条启动路线standalone 一把梭与伪集群三步走装完配置接下来是启动。这里有个选择要不要直接上伪集群。我的建议是先用 standalone 把链路跑通、确认版本和 JDK 没问题再拆成三个进程。直接上伪集群的话一旦起不来你不确定是配置错、元数据没初始化还是端口被占排查面一下就散了。4.1 standalone最快跑通但别拿它当生产standalone 会在一个 JVM 里把 ZooKeeper、BookKeeper、broker 全拉起来对外端口和伪集群一致客户端代码不用改。cd /opt/pulsar/current # 前台跑日志直接打屏幕上方便盯第一屏 bin/pulsar standalone --no-functions-worker --no-stream-storage两个参数值得说。--no-functions-worker不启动函数计算 worker能省下几百 MB 内存如果你只是验证消息收发用不上它。--no-stream-storage关掉和流存储相关的组件比如对接对象存储那部分同样是为了减负。两个都不加也能起来就是内存占用会明显高一截小机器上容易 OOM。想后台跑就把bin/pulsar换成bin/pulsar-daemonbin/pulsar-daemon start standalone # 日志在 logs/pulsar-standalone.log tail -f logs/pulsar-standalone.logpulsar-daemon启动后进程脱离终端日志落文件适合放一段时间慢慢测。判断“起来了”的标准不是看到某一行日志而是 8080 的健康检查接口返回 ok这一点放到最后验证那一章说。standalone 的数据全在data/目录下zookeeper、bookkeeper的 journal 和 ledger 都在里面。想推倒重来bin/pulsar-daemon stop standalone rm -rf data/删之前一定先停进程。进程还在的时候删data/ZK 会拿着已经删掉的文件句柄继续跑表面正常但写进去的东西落不了盘重启后全部丢失——这个坑挺隐蔽我吃过一次。提示standalone 适合验证功能、跑例子、写客户端 demo不适合压测。它所有组件挤在一个 JVM 里GC 会互相影响测出来的延迟数据没有参考价值。4.2 伪集群元数据初始化的顺序不能乱伪集群是把 ZooKeeper、BookKeeper、broker 分成三个进程跑在同一台机器上。顺序是 ZK → 格式化 BK 元数据 → 写集群元数据 → bookie → broker中间任何一步跳过后面都会以各种奇怪的方式报错。cd /opt/pulsar/current # 1. 先起 ZooKeeper元数据都往里写 bin/pulsar-daemon start zookeeper # 等一下确认 2181 已经在听 ss -lntp | grep 2181 # 2. 格式化 BookKeeper 元数据全新集群只做一次 bin/bookkeeper shell metaformat -nonInteractive # 3. 写集群级元数据集群名、ZK 地址、对外服务地址 bin/pulsar initialize-cluster-metadata \ --cluster pulsar-cluster \ --zookeeper 127.0.0.1:2181 \ --configuration-store 127.0.0.1:2181 \ --web-service-url http://127.0.0.1:8080 \ --broker-service-url pulsar://127.0.0.1:6650 # 4. 起 bookie bin/pulsar-daemon start bookie # 5. 起 broker bin/pulsar-daemon start broker逐个说参数。metaformat那条的-nonInteractive是跳过交互确认脚本里跑必须加不然会卡在提示符上等你输 y。这一步做的事情是在 ZK 的/ledgers路径下写入 BookKeeper 的格式版本做过一次再跑会报“already formatted”看到这个报错说明之前已经格式化过别慌继续下一步。initialize-cluster-metadata的五个参数里--cluster是集群名必须和conf/broker.conf里的clusterName完全一致--zookeeper对应zookeeperServers--configuration-store对应configurationStoreServers单集群部署时两者一般指同一个地址多集群才需要分开后面两个是 broker 对外公布的地址客户端和pulsar-admin都靠它们找服务写成127.0.0.1就只能本机用跨机器访问必须换成本机真实 IP 或者域名。关于第 2 步和第 3 步的先后我见过两种说法。有的部署顺序里initialize-cluster-metadata会顺带把 BookKeeper 元数据一起写掉但不同小版本的实现细节不完全一样我一般还是显式先metaformat再初始化集群元数据每次都这么走没出过问题。反过来先初始化再格式化有概率把刚写好的集群元数据冲掉之后 broker 起来的表现是找不到集群。4.3 broker.conf 与 bookkeeper.conf 的对齐伪集群起不来的原因八成出在这两份配置对不上。列一下必须对齐的几项# conf/broker.conf clusterNamepulsar-cluster zookeeperServers127.0.0.1:2181 configurationStoreServers127.0.0.1:2181 # 2.9 用 URI 形式告诉 broker 去哪里找 bookie 的元数据 bookkeeperMetadataServiceUrizkhierarchical://127.0.0.1:2181/ledgers # 对外公布地址跨机访问必须改成真实 IP advertisedAddress127.0.0.1 brokerServicePort6650 webServicePort8080 # 演示环境允许自动建 topic生产一般关掉 allowAutoTopicCreationtrue# conf/bookkeeper.conf metadataServiceUrizkhierarchical://127.0.0.1:2181/ledgers advertisedAddress127.0.0.1 bookiePort3181几处容易写错的地方。bookkeeperMetadataServiceUri和 bookie 侧的metadataServiceUri必须指向同一个 ZK 路径一个是 broker 视角、一个是 bookie 视角路径不一致就变成“broker 去 A 找 bookiebookie 在 B 注册”表现是 broker 起来了但写不进 ledger。allowAutoTopicCreation在 2.9 里是可以按 namespace 覆盖的broker 级设成 true 只是给演示环境开个方便生产上多半会关掉改成在 namespace 上显式声明。advertisedAddress是最容易被忽略的一项。留空或者写127.0.0.1的时候broker 会把自己公布的地址定成本机回环本机客户端一切正常另一台机器连过来就是一直超时——因为客户端从 ZK 里拿到的服务地址是127.0.0.1:6650在它自己机器上指回它自己。测试机有固定 IP 的话这里直接写 IP。改完配置重启 broker 才生效bin/pulsar-daemon stop broker bin/pulsar-daemon start broker tail -n 100 logs/pulsar-broker.log日志里出现messaging service is ready且没有Cluster not found、Error while initializing metadata这类字样基本算起来了。最终判据还是放最后验证那一章。5. 避坑排查起不来、连不上、写不进去的三类现场下面几条都是我在不同机器上反复遇到的现象看着五花八门归因其实就那么几个。每条按现象、原因、解决写对着看就行。5.1 进程秒退日志第一屏就有异常栈现象bin/pulsar standalone敲下去不到十秒回到命令提示符logs/下日志只有几十行最上面是java.lang.UnsupportedClassVersionError或者一长串InaccessibleObjectException。用bin/pulsar-daemon起的话ps里根本看不到进程。原因JDK 版本不对。前者是用了 Java 8 以下的运行时后者是用 Java 17 及以上跑 2.9.1Netty 和 BookKeeper 的反射调用被模块系统拦掉。还有一个变种是JAVA_HOME指向一个已经不存在的路径脚本 fallback 到 PATH 里那个 java版本完全不受控。解决先readlink -f $(which java)和echo $JAVA_HOME两条一起看确认实际用的是哪个。把JAVA_HOME显式指到 JDK 11写进运行用户的 profile别只改 root 的。改完重新登录会话再起bash里的环境变量缓存有时会骗人。5.2 本机能通另一台机器连 6650 一直超时现象本机bin/pulsar-client produce收发正常8080 的健康检查也 ok。同事在他机器上把服务地址填成你的 IP连上去就一直卡最后 timeout服务端日志干干净净什么都没有。原因advertisedAddress或者initialize-cluster-metadata里的--broker-service-url写的是127.0.0.1。客户端启动时先到 ZK 里查 broker 公布的服务地址拿到127.0.0.1:6650之后就在自己机器上连回环地址自然连不上。服务端连请求包都没收到所以日志里没痕迹。解决两处都要改。conf/broker.conf的advertisedAddress换成本机在局域网里的真实 IP如果已经跑过initialize-cluster-metadata还需要重新执行一遍把--broker-service-url和--web-service-url改成真实 IP。改完重启 broker。想确认改没改对用bin/pulsar-admin brokers list pulsar-cluster看输出的地址。5.3 broker 起来了pulsar-admin clusters list却是空的现象三个进程都在端口也都在听但bin/pulsar-admin clusters list返回空数组建 tenant 的时候报Cluster not found。logs/pulsar-broker.log里能翻到Cluster pulsar-cluster doesnt exist。把conf/broker.conf的clusterName改成standalone就好了。原因broker 启动时会拿clusterName去 ZK 里找对应的集群元数据。initialize-cluster-metadata --cluster pulsar-cluster写进去的是pulsar-cluster而broker.conf里如果还是模板默认的standalone两边对不上broker 就认为自己不属于任何集群。这个默认值在 standalone 模式下是对的切到伪集群忘了改就出事。解决conf/broker.conf里clusterName改成和初始化时--cluster完全一致的值大小写、连字符都要一样重启 broker。已经建过 tenant 的环境别随手改集群名改名等于换了一个集群旧数据还在但 admin 看不见。5.4 bookie 起不来或者起来了但写不进 ledger现象bin/pulsar-daemon start bookie之后logs/pulsar-bookie.log里反复出现Metadata service Uri is not formatted或者Bookie has multiple journals and ledgers on same disk的告警broker 侧 produce 报Failed to write entrytopic 能建但storageSize一直是 0。原因三种。一是漏了bin/bookkeeper shell metaformat或者格式化之后又改了metadataServiceUri里的 ZK 路径导致 bookie 去一个没格式化的路径下找元数据。二是journalDirectory和ledgerDirectories指向同一块盘同一个目录bookie 直接拒绝启动。三是数据目录属主不对bookie 用 pulsar 用户跑但/data/pulsar还是 root 的。解决先看metadataServiceUri里的 ZK 路径/ledgers这个后缀一旦定下来就别改确认格式化确实执行过ls -ld /data/pulsar/*检查属主不对就chown -R pulsar:pulsar /data/pulsar。如果是同盘告警至少把 journal 挪到另一个目录测试机上挪到/data/pulsar-journal就行。改完bin/pulsar-daemon stop bookie再 start。5.5 明明没装过 ZooKeeper2181 却已经被占现象bin/pulsar-daemon start zookeeper立刻失败日志里Address already in use。ss -lntp | grep 2181看到一个不认识的进程名。原因机器上已经有别的组件在用 ZooKeeper或者上一次 Pulsar 的 ZK 进程没退干净stop之后没等它真正结束就重新 start这种情况在脚本里连着跑特别常见。解决先ps -ef | grep -i zookeeper看是谁。是残留进程就 kill 掉再起是别的组件在用两条路——把conf/zookeeper.conf的clientPort和 broker、bookie 配置里的 ZK 地址一起换到 2182 之类的端口或者干脆让 Pulsar 复用那个 ZK前提是版本 3.5 以上且愿意共用根节点。共用的话metadataServiceUri里的路径要加个前缀区分开别和别人的混在一个根下。6. 装完怎么验证把链路真正跑通的一串命令判断“装好没有”我一直用同一个判据能发能收并且数据真的落到了 ledger 上。端口在听、日志有 ready 字样都不算数那只是进程活着。下面这一串命令按从外到内的顺序走哪一步断了就停在哪一步比翻日志快。cd /opt/pulsar/current # 1. 健康检查最外层的判据 curl -s http://127.0.0.1:8080/admin/v2/brokers/health # 期望输出ok # 2. 集群和 broker 有没有正确注册 bin/pulsar-admin clusters list bin/pulsar-admin brokers list pulsar-cluster # 3. 建一个 tenant 和 namespace顺便验证元数据写入 bin/pulsar-admin tenants create demo bin/pulsar-admin namespaces create demo/ns1 # 4. 发一条消息 bin/pulsar-client produce persistent://demo/ns1/hello \ --messages first-message -n 1 # 5. 消费回来 bin/pulsar-client consume persistent://demo/ns1/hello \ -s verify-sub -n 1 -t Exhausted第一步的/admin/v2/brokers/health是 broker 自检接口返回ok说明它能连上 ZK、能读元数据。这一步失败先查 8080 端口和 broker 日志别往下走。第二步的clusters list应该能看到初始化时写的pulsar-clusterbrokers list应该输出 broker 公布的服务地址。如果前者是空的回到 5.3 那节查clusterName。第四步的--messages后面跟的是消息体-n 1是发一条。第五步的-s是订阅名-n 1是收一条就退-t Exhausted是让客户端收完自动结束——不加这个参数消费命令会一直挂着等新消息很多人以为卡死了其实是正常行为。最后一步是我认为最关键的# 看 topic 的统计信息重点看 storageSize 和 ledgerCount bin/pulsar-admin topics stats persistent://demo/ns1/hello \ | grep -E storageSize|ledgerCount|msgInCounterstorageSize大于 0 才说明消息真的写进 BookKeeper 的 ledger 了ledgerCount至少是 1。如果msgInCounter是 1 但storageSize还是 0说明消息在内存里没落盘多半是 bookie 那边没连上——这时候去看logs/pulsar-bookie.log通常能看到大量重连 ZK 的记录。ledgerCount一路涨到几十上百而storageSize很小那是滚动策略在起作用属于正常。验证项命令关键部分期望结果Broker 自检/admin/v2/brokers/health返回ok集群注册pulsar-admin clusters list包含pulsar-cluster元数据写入tenants createnamespaces create无报错返回端到端收发pulsar-client produce/consume消费到同一条内容数据落盘topics stats的storageSize大于 0还有一个容易忽略的点验证完把 standalone 换成伪集群的话data/目录不能直接沿用。standalone 的 ZK 数据在data/standalone/下面伪集群的指向/data/pulsar/zookeeper两边元数据格式不同混用会让 bookie 找不到集群。换模式之前先停进程、清目录老老实实重新初始化一遍。从那以后我每次装完 Pulsar不管多急都会先把produce加consume这对命令跑一遍再瞄一眼storageSize。端口在听不算装好能发能收还能落盘才算。希望帮到你。本文还有配套的精品资源点击获取