社区知识库｜常见问答 FAQ 集合第 1 期

平时在 Pulsar 交流群中，我们发现大家在接触和使用 Pulsar 的过程中，会反复遇到相类似的问题。为了更高效地解决大家这些“高频疑问”，同时也对提出优质问题的朋友表示感谢，我们特别建立了 FAQ 知识库，以便于收集及解答大家的疑问。

我们将定期收集筛选社群内提出的高频问题，由社区专家甄别筛选出其中优质的提问进行回答，整合优化后分享给社区的小伙伴们作为遇到问题时的优先参考，希望可以帮助大家解决使用 Pulsar 过程中的问题。

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

Ledger 位置查询

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

解答：默认情况下，Ledgers 的所有数据都存在在 data/bookkkeeper/ledgers 的目录下。可以通过 bin/bookkeeper shell ledgermetadata -ledgerid 来查看 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 中文交流群