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

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

下面来看看本次收集的问题吧:

Node.js 客户端 Broker 配置

问题 1: Pulsar Node.js 客户端配置多个 Broker,只要第一个 Broker 挂掉了,生产者和消费者就无法建立连接。客户端为什么只连配置里的第一个 Broker?

解答:如果 Pulsar Node.js 客户端配置多个 Broker,只要第一个 Broker 挂掉了,生产者和消费者就无法建立连接。客户端为什么只连配置里的第一个 Broker? 不支持配置多个 Service URL,可以通过 DNS 或者 L4 proxy 代理 Broker 的方式来解决,Client 连接域名或者 L4 proxy。Java Client/Go Client 等已经都有多个 Service URL 的支持。Node.js Client 可以在后续的版本中增加在多个 Service URL 的支持。

Topic 数量及其影响

问题 2: 在几千个生产者的前提下,设计 Pulsar topic 时应选择都发到一个 topic,还是分别发送对应数量的 topic?

解答:在 Pulsar 中每个 Partition 只能由一个 Broker 负责,也就是说如果只有一个 Partition 的 Topic 流量超过 Broker 的负载极限时就无法扩展了,可以将一个 Topic 的多个 Partition 分配到多个 Broker 上,因此可以利用多个 Broker 的资源。所以不应该按照客户端的数量来决定主题的数量或者是主题的 Partition 的数量,应该按照具体的业务场景,对 Topic 的性能要求来决定。

问题 3: Topic 数量多会产生什么影响?

解答:Topic/Partition 增多时,Metadata Server 承受主要的压力,几万及以下的量级可以基本不用考虑这个问题。然而当到了几十万上百万 Topic 的时候,对 Metadata Server 会有比较高的要求。

问题 4: 多主题订阅时,一个客户端订阅的 Topic 有上限吗?

解答:Pulsar 对一个客户端能订阅的 Topic 数量是没有限制的,但是最终会因为物理限制而无法再订阅更多的 Topic,比如内存限制。

Bookie

问题 5: Bookie 磁盘满了一般怎么处理?

解答:正常情况下可以等过期删除数据,最快的方式是 Delete Topic。

游标

问题 6: 为什么 markDeletePosition 和 readPosition 的角标差距很大?

解答:Reader 没有 markDeletePosition 的概念。因为是临时游标,所以在初始化时 start position 即 markDeletePosition,也不会再更改。

查询 Topic 资源

问题 7: Pulsar 查询主题内数据的工具。

解答:我们一般可以使用 pulsar-admin 去查看 Topic(主题)内的资源。详情参见官网

  • 比如你可以用它来获取 Topic 的 Metadata:admin.topics().getPartitionedTopicMetadata(topicName);
  • 用来获取一个 Topic 的状态:admin.topics().getStats(topic);
  • 或者根据 MessageId 来获取 Topic 内的消息:admin.topics().getMessageById(topic, ledgerId, entryId);
  • ...

问题 8: Pulsar 消费端的 offset 存在什么位置?

解答:Pulsar 消费端提交的不是 offset,而是 MessageId,主要是 ledger id 和 entry id,streamnative/kop#389 支持 batch index 级别的 ACK。消费者提交的 MessageId 保存在 BookKeeper 中的,对应单独的 ledger。

以上就是第 3 期社区 FAQ 汇总,在此感谢参与社群日常提问与解答的小伙伴们。让我们期待下一期的 FAQ 内容吧!

相关推荐


ApachePulsar
192 声望939 粉丝

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