共计 3258 个字符,预计需要花费 9 分钟才能阅读完成。
平时在 Pulsar 交换群中,咱们发现大家在接触和应用 Pulsar 的过程中,会重复遇到相相似的问题。为了更高效地解决大家这些“高频疑难”,同时也对提出优质问题的敌人表示感谢,咱们特地建设了 FAQ 知识库,以便于收集及解答大家的疑难。
咱们将定期收集筛选社群内提出的高频问题,由社区专家甄别筛选出其中优质的发问进行答复,整合优化后分享给社区的小伙伴们作为遇到问题时的优先参考,心愿能够帮忙大家解决应用 Pulsar 过程中的问题。
上面来看看本次收集的问题吧:
音讯保留
问题 1: 在 Pulsar 的音讯保留机制里,Pulsar 的音讯被一个消费者 Ack 后就会进入保留策略。那么在多个消费者订阅了一个 Topic、某条音讯的局部消费者 Ack 的状况下,这条音讯是否会进入保留策略?
解答:只有音讯在所有订阅里都被 ACK,才会进一步由保留策略解决。对于同一个订阅,由哪个消费者进行 ACK 不重要,只有被 ACK 一次,在这个订阅里音讯就是曾经被 ACK 的状态。具体可参考:https://pulsar.apache.org/doc…
重试次数
问题 2: Pulsar 反对参数配置重试次数吗?
解答:不反对。Pulsar 依照工夫来进行退却重试策略,和重试次数机制相似。客户端外部的重试策略是用的退却(backoff)机制,能够配置 ClientBuilder 的 backoff
参数来管制。
/**
* Set the duration of time for a backoff interval.
*
* @param duration the duration of the interval
* @param unit the time unit in which the duration is defined
* @return the client builder instance
*/
ClientBuilder startingBackoffInterval(long duration, TimeUnit unit);
/**
* Set the maximum duration of time for a backoff interval.
*
* @param duration the duration of the interval
* @param unit the time unit in which the duration is defined
* @return the client builder instance
*/
从生产者的角度,能够在 ProducerBuilder 中配置总的 send timeout。
/**
* Set the send timeout <i>(default: 30 seconds)</i>.
*
* <p>If a message is not acknowledged by the server before the sendTimeout expires, an error will be reported.
*
* <p>Setting the timeout to zero, for example {@code setTimeout(0, TimeUnit.SECONDS)} will set the timeout
* to infinity, which can be useful when using Pulsar's message deduplication feature, since the client
* library will retry forever to publish a message. No errors will be propagated back to the application.
*
* @param sendTimeout
* the send timeout
* @param unit
* the time unit of the {@code sendTimeout}
* @return the producer builder instance
*/
ProducerBuilder<T> sendTimeout(int sendTimeout, TimeUnit unit)
Pulsar Perf
问题 3: 用 Pulsar Perf 来生产数据,然而无积压。
解答:在 Pulsar Perf 生产数据之前先创立 Subscription。
压测工具
问题 4: 如何对 Pulsar 压测呢?应用什么工具?
解答:Pulsar 压测工具目前有 Pulsar Perf 和 OpenMessaging Benchmark,应用详情参考以下链接:
- https://pulsar.apache.org/doc…
- http://openmessaging.cloud/do…
音讯提早
问题 5: Pulsar 服务端默认反对提早投递吗?
解答:Delay message 只在 Shared(共享)订阅模式失效。如果未失效,须要首先查看订阅模式是不是 Shared(共享),Pulsar 自身默认 Exclusive(独占)订阅模式;同时应防止 delay message 在 KeyShared(键共享)模式下失效,Delay message 和 Key_Shared 语义是违反的。
Broker 宕机
问题 6: 如果 Broker 宕机,音讯如何告诉到下一个 broker?
解答:Broker 自身无状态。
- Broker 在宕机时,不会被动告诉其余 broker,散布在这个 broker 上的所有 bundle(bundle 是 topic 汇合,是 Pulsar topic 进行负载平衡的最小单位)都会执行 unload 操作,unload 操作的流程:
- 敞开 unload 中所有 topic 的生产者、消费者和复制机;
- 敞开 Managedledger。当所有 bundle 都 unload 实现后,这个 broker 就能够失常退出。
- 如果是 broker 异样退出,这个 broker 上的所有 bundle 也会被强行去掉对应归属,即这个 bundle 不在归属于这个 Broker。
当生产者或消费者客户端须要持续向某个 topic 发送 / 接管音讯时,会首先执行 lookup 申请,会依照 loadbalance 策略找到指标 broker 节点(以后是 load 最低的节点),将对应 bundle onLoad 到指标 broker。待 onLoad 实现后,这个 broker 就能够持续为该 topic 提供读写服务了。
另外,Broker 在 ZooKeeper 上的一些长期节点信息,会被动删除;或因为超时而断开、其余 Broker 监听后,会进行相应的操作。
Compaction 限流
问题 7: 磁盘占用很重大,磁盘清理文件的速度远远跟不上写的速度,调整了 BookKeeper 参数 gcWaitTime、majorCompactionInterval、minorCompactionInterval
成果不显著,是否还有其余解决方案?
解答:Compaction 有一个限流策略,从你的形容来看,应该是 Compaction 比较慢,能够调整 isThrottleByBytes=true
,并且减少 compactionRateByBytes
的限流阈值。
# Throttle compaction by bytes or by entries.
isThrottleByBytes=false
# Set the rate at which compaction will readd entries. The unit is adds per second.
compactionRateByEntries=1000
# Set the rate at which compaction will readd entries. The unit is bytes added per second.
compactionRateByBytes=1000000
Pulsar 权限
问题 8: Pulsar 权限相干材料。
解答:
- 视频:https://www.bilibili.com/vide…
- 文档:https://pulsar.apache.org/doc…
以上就是第 4 期社区 FAQ 汇总,在此感激参加社群日常发问与解答的小伙伴们。让咱们期待下一期的 FAQ 内容吧!
相干举荐
- 社区知识库|常见问答 FAQ 汇合第 1 期
- 社区知识库|常见问答 FAQ 汇合第 2 期
- 社区知识库|常见问答 FAQ 汇合第 3 期