平时在 Pulsar 交换群中，咱们发现大家在接触和应用 Pulsar 的过程中，会重复遇到相相似的问题。为了更高效地解决大家这些“高频疑难”，同时也对提出优质问题的敌人表示感谢，咱们特地建设了 FAQ 知识库，以便于收集及解答大家的疑难。

咱们将定期收集筛选社群内提出的高频问题，由社区专家甄别筛选出其中优质的发问进行答复，整合优化后分享给社区的小伙伴们作为遇到问题时的优先参考，心愿能够帮忙大家解决应用 Pulsar 过程中的问题。

上面来看看本次大家遇到了哪些问题吧：

Ledger 地位查问

问题 1：如何查问 Ledger 数据？

解答：默认状况下，Ledgers 的所有数据都存在在 data/bookkkeeper/ledgers 的目录下。能够通过 bin/bookkeeper shell ledgermetadata -ledgerid <lid> 来查看 Ledger 在哪几个 BookKeeper 上。

问题 2：如何查问 Ledger 在哪个磁盘？

解答：能够加一个 API 命令，通过 ledgerId % numberOfDirectories 计算出某个 Ledger 所在磁盘。

AutoRecovery 限速

问题 3：Pulsar 的 AutoRecovery 如何限速？

解答：目前不能限速，然而 BookKeeper 社区有 PR-2778 进行中，将通过增加 throttleWriteRateByBytes throttleReadRateByEntries 来实现 Auto Recovery 的限速性能。

Broker 无奈启动 – ZooKeeper 报错

问题 4：Broker 无奈启动，报错 ZooKeeper Session 0x0 closed，Failed to create ZooKeeper Client。

解答：通常状况下 Broker 无奈启动、ZooKeeper 报错，就须要查看 Broker 节点是否能正确连贯上 ZooKeeper。本状况下因为 Bookie 连贯 ZooKeeper 集群呈现 Session 超时，须要查看 ZooKeeper 集群是否失常启动。

topic 删除 / 策略

问题 5：Pulsar 在 topic 层级进行过生产或生产受权之后，无论之后是否勾销权限或者删除 topic，在 ZookKeeper 上的数据都统一存在，会不会导致数据越积越多吗？删除 topic 之后再新增一个同名的 topic，新旧策略是否抵触？

解答：这个问题正在修复，预计在 Pulsar 2.8.2 版本公布。PR 12215 将通过增加单元测试来实现在删除 topic 同时删除 topic 受权策略，解决 ZooKeeper 数据积压的问题。

命名空间

问题 6：“在命名空间层级指定 bundle 或者订阅名来革除 backlog”的设计次要是应对于什么场景？

解答：利用场景是为了清理这个 namespace/bundle 上面的所有特定订阅名的 backlog，来简化在 topic 数量比拟多的时候须要顺次解决每个 topic 的操作。

topic 订阅（Kafka VS Pulsar）

问题 7：在 Kafka 中，生产组是一个集群的概念，一个生产组订阅多个 topic，所有 consumer 都受这个生产组 rebalance 的影响。Pulsar 是否像 Kafka 一样，在用同一个订阅名订阅不同的 topic 时存在潜在的危险？

解答：Pulsar 没有相似 Kafka 的危险。Kafka 的 group 是不和任何 topic 绑定的，元数据记录的是 group 上面有多少个 topic。当一个 consumer 退出时，通过 JOIN_GROUP 和 SYNC_GROUP 操作，group leader（client）会实现 assignment，借由 broker（group coordinator）告诉到 group followers（其它 client）。即便调配计划不变，其它 topic 也会进行 rebalance。

Pulsar 的 subscription 是隶属于 topic 的，在 broker 外部实现中，每个 topic 被形象为 PersistentTopic（这里以默认的长久化 topic 为例），而 PersistentTopic 上面能够有多个 PersistentSubscription，对应每个 subscription（也就是 Kafka 的 group）。因为 Pulsar 是 push 生产模型，每个 PersistentSubscription 都会依据订阅类型（比方 Failover）创立对应的 Dispatcher。

Pulsar 没有再均衡（rebalance），新的 consumer 退出 subscription 后，也会连贯到 owner broker（对应 Kafka 的 topic leader），只不过 broker 端的 dispatcher 可能不发消息给它罢了。Broker 感知到 namespace bundle ownership 发生变化时，如果有 topic/partition 不再属于以后 broker，会被动断开连接，而后 consumer 重连到新的 owner broker。

简略说：

• 在 Pulsar 中，新 consumer 退出 subscription，影响的 dispatcher 是对应 topic 上面的 subscription 所领有的，不会影响其它 topic 的 subscription 的 dispatcher。
• 在 Kafka 中，新 consumer 退出 group，group 所领有的 topic 都要进行 rebalance。

Pulsar 降级报错 – 2.7.0 降级 2.8.0

问题 8：从 2.7.0 降级到 2.8.0 之后，broker 呈现报错：

Error deserializing message for expiry check
java.lang.IllegalStateException: Field 'publish_time' is not set
        at org.apache.pulsar.common.api.proto.MessageMetadata.getPublishTime(MessageMetadata.java:76) ~[org.apache.pulsar-pulsar-common-2.8.0.jar:2.8.0]
        at org.apache.pulsar.client.impl.MessageImpl.getPublishTime(MessageImpl.java:335) ~[org.apache.pulsar-pulsar-client-original-2.8.0.jar:2.8.0]
        at org.apache.pulsar.client.impl.MessageImpl.isExpired(MessageImpl.java:349) ~[org.apache.pulsar-pulsar-client-original-2.8.0.jar:2.8.0]
        at org.apache.pulsar.broker.service.persistent.PersistentMessageExpiryMonitor.lambda$expireMessages$0(PersistentMessageExpiryMonitor.java:79) ~[org.apache.pulsar-pulsar-broker-2.8.0.jar:2.8.0]
        at org.apache.bookkeeper.mledger.impl.OpFindNewest.readEntryComplete(OpFindNewest.java:89) ~[org.apache.pulsar-managed-ledger-2.8.0.jar:2.8.0]
        at org.apache.bookkeeper.mledger.impl.EntryCacheImpl.lambda$asyncReadEntry0$0(EntryCacheImpl.java:229) ~[org.apache.pulsar-managed-ledger-2.8.0.jar:2.8.0]
        at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760) [?:1.8.0_121]
        at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736) [?:1.8.0_121]
        at java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:442) [?:1.8.0_121]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_121]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_121]
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [io.netty-netty-common-4.1.63.Final.jar:4.1.63.Final]
        at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]

解答：能够尝试更稳固的 Pulsar 2.8.1 版本。PR-11014 已解决当 broker 元数据条目在没有 AppendBrokerTimestampMetadataInterceptor 就启动的时候，publish_time 不报错的问题。

以上就是第 1 期社区 FAQ 汇总，在此感激参加社群日常发问与解答的小伙伴们。让咱们期待下一期的 FAQ 内容吧！

关注公众号「Apache Pulsar」，获取干货与动静

退出 Apache Pulsar 中文交换群 👇🏻