平时在 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 中文交流群👇🏻


ApachePulsar
192 声望939 粉丝

Apache软件基金会顶级项目,下一代云原生分布式消息系统