共计 1798 个字符,预计需要花费 5 分钟才能阅读完成。
平时在 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 内容吧!
相干举荐
- 社区知识库|常见问答 FAQ 汇合第 1 期
- 社区知识库|常见问答 FAQ 汇合第 2 期