乐趣区

关于apache:Apache-Pulsar-在-BIGO-的性能调优实战上

jiezi

背景

在人工智能技术的反对下，BIGO 基于视频的产品和服务受到宽泛欢送，在 150 多个国家 / 地区领有用户，其中包含 Bigo Live（直播）和 Likee（短视频）。Bigo Live 在 150 多个国家 / 地区衰亡，Likee 有 1 亿多用户，并在 Z 世代中很受欢迎。

随着业务的迅速增长，BIGO 音讯队列平台承载的数据规模呈现了成倍增长，上游的在线模型训练、在线举荐、实时数据分析、实时数仓等业务对音讯的实时性和稳定性提出了更高的要求。

BIGO 音讯队列平台应用的是开源 Kafka，然而随着业务数据量的成倍增长、音讯实时性和零碎稳定性要求一直进步，多个 Kafka 集群的保护老本越来越高，次要体现在：

  • 数据存储和音讯队列服务绑定，集群扩缩容 / 分区平衡须要大量拷贝数据，造成集群性能降落
  • 当分区正本不处于 ISR（同步）状态时，一旦有 broker 产生故障，可能会造成丢数或该分区无奈提供读写服务
  • 当 Kafka broker 磁盘故障 / 使用率过高时，须要进行人工干预
  • 集群跨区域同步应用 KMM(Kafka Mirror Maker)，性能和稳定性难以达到预期
  • 在 catch-up 读场景下，容易呈现 PageCache 净化，造成读写性能降落
  • 尽管 Kafka 的 topic partition 是程序写入，然而当 broker 上有成千盈百个 topic partition 时，从磁盘角度看就变成了随机写入，此时磁盘读写性能会随着 topic partition 数量的减少而升高，因而 Kafka broker 上存储的 topic partition 数量是有限度的
  • 随着 Kafka 集群规模的增长，Kakfa 集群的运维老本急剧增长，须要投入大量的人力进行日常运维。在 BIGO，扩容一台机器到 Kafka 集群并进行分区平衡，须要 0.5 人 / 天；缩容一台机器须要 1 人 / 天

为了进步音讯队列实时性、稳定性和可靠性，升高运维老本，咱们重新考虑了 Kafka 架构设计上的有余，调研是否从架构设计上解决这些问题，满足以后的业务要求。

下一代音讯流平台：Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体。Pulsar 于 2016 年由 Yahoo 开源并捐献给 Apache 软件基金会进行孵化，2018 年成为 Apache 软件基金会顶级我的项目。

Pulsar 采纳计算与存储拆散的分层架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐以及低延时的高可扩大流数据存储个性。

Pulsar 吸引咱们的次要个性如下：

  • 线性扩大：可能无缝扩容到成千盈百个节点
  • 高吞吐：曾经在 Yahoo 的生产环境中禁受了考验，反对每秒数百万音讯的 公布 - 订阅（Pub-Sub）
  • 低提早：在大规模的音讯量下仍然可能放弃低提早（小于 5 ms）
  • 长久化机制：Plusar 的长久化机制构建在 Apache BookKeeper 上，提供了读写拆散
  • 读写拆散：BookKeeper 的读写拆散 IO 模型极大施展了磁盘程序写性能，对机械硬盘绝对比拟敌对，单台 bookie 节点撑持的 topic 数不受限制

Apache Pulsar 的架构设计解决了咱们应用 Kafka 过程中遇到的各种问题，并且提供了很多十分棒的个性，如多租户、音讯队列和批流交融的生产模型、强一致性等。

为了进一步加深对 Apache Pulsar 的了解，掂量 Pulsar 是否真正满足咱们生产环境大规模音讯 Pub-Sub 的需要，咱们从 2019 年 12 月份开始进行了一系列压测工作。因为咱们应用的是机械硬盘，没有 SSD，在压测过程中遇到了一些列性能问题，非常感谢 StreamNative 同学的帮忙，感激斯杰、翟佳、鹏辉的急躁领导和探讨，通过一系列的性能调优，一直进步 Pulsar 的吞吐和稳定性。

通过 3~4 个月的压测和调优，2020 年 4 月份咱们正式在生产环境中应用 Pulsar 集群。咱们采纳 bookie 和 broker 在同一个节点的混部模式，逐渐替换生产环境的 Kafka 集群。截止到目前为止，生产环境中 Pulsar 集群规模为十几台，日解决音讯量为百亿级别，并且正在逐渐扩容和迁徙 Kafka 流量到 Pulsar 集群。

压测 / 应用 Pulsar 遇到的问题

大家在应用 / 压测 Pulsar 时，可能会遇到如下问题：

  1. Pulsar broker 节点负载不平衡。
  2. Pulsar broker 端 Cache 命中率低，导致大量读申请进入 bookie，且读性能比拟差。
  3. 压测时经常出现 broker 内存溢出景象（OOM）。
  4. Bookie 呈现 direct memory OOM 导致过程挂掉。
  5. Bookie 节点负载不平衡，且常常抖动。
  6. 当 Journal 盘为 HDD 时，尽管敞开了 fsync，然而 bookie add entry 99th latency 仍旧很高，写入性能较差。
  7. 当 bookie 中有大量读申请时，呈现写被反压，add entry latency 回升。
  8. Pulsar client 经常出现“Lookup Timeout Exception”。
  9. ZooKeeper 读写提早过高导致整个 Pulsar 集群不稳固。
  10. 应用 reader API(eg. pulsar flink connector) 生产 Pulsar topic 时，生产速度较慢（Pulsar 2.5.2 之前版本）。

当 Journal/Ledger 盘为机械硬盘（HDD）时，问题 4、5、6、7 体现得尤为重大。这些问题直观来看，是磁盘不够快造成的，如果 Journal/Ledger 盘读写速度足够快，就不会呈现音讯在 direct memory 中沉积，也就不会有一系列 OOM 的产生。

因为在咱们音讯队列生产零碎中，须要存储的数据量比拟大 (TB ~ PB 级别)，Journal 盘和 Ledger 盘都是 SSD 须要较高的老本，那么有没有可能在 Pulsar / BookKeeper 上做一些参数 / 策略的优化，让 HDD 也能施展出较好的性能呢?

在压测和应用 Pulsar 过程中，咱们遇到了一系列性能问题，次要分为 Pulsar Broker 层面和 BookKeeper 层面。为此，本系列性能调优文章分为两篇，别离介绍 BIGO 在应用 Pulsar 过程中对 Pulsar Broker 和 Bookkeeper 进行性能调优的解决方案，以使得 Pulsar 无论在磁盘为 SSD 还是 HDD 场景下，都能取得比拟好的性能。

因为篇幅起因，本次性能调优系列分为两局部，上半局部次要介绍 Pulsar broker 的性能调优，下半局部次要介绍 BookKeeper 与 Pulsar 联合过程中的性能调优。

本文接下来次要介绍 Pulsar / BookKeeper 中和性能相干的局部，并提出一些性能调优的倡议（这些性能调优计划曾经在 BIGO 生产零碎中稳固运行，并取得了不错的收益）。

环境部署与监控

环境部署与监控

因为 BookKeeper 和 Pulsar Broker 重度依赖 ZooKeeper，为了保障 Pulsar 的稳固，须要保障 ZooKeeper Read/Write 低提早。此外，BookKeeper 是 IO 密集型工作，为了防止 IO 之间相互烦扰，Journal/Ledger 放在独立磁盘上。总结如下：

  • Bookie Journal/Ledger 目录放在独立磁盘上
  • 当 Journal/Ledger 目录的磁盘为 HDD 时，ZooKeeper dataDir/dataLogDir 不要和 Journal/Ledger 目录放在同一块磁盘上

BookKeeper 和 Pulsar Broker 均依赖 direct memory，而且 BookKeeper 还依赖 PageCache 进行数据读写减速，所以正当的内存调配策略也是至关重要的。Pulsar 社区的 sijie 举荐的内存调配策略如下：

  • OS: 1 ~ 2 GB

  • JVM: 1/2

    • heap: 1/3
    • direct memory: 2/3
  • PageCache: 1/2

假如机器物理内存为 128G，bookie 和 broker 混部，内存调配如下：

  • OS: 2GB

  • Broker: 31GB

    • heap: 10GB
    • direct memory: 21GB

  • Bookie: 32GB

    • heap: 10GB
    • direct memory: 22GB
  • PageCache: 63GB

Monitor：性能调优，监控后行

为了更加直观地发现零碎性能瓶颈，咱们须要为 Pulsar/BookKeeper 搭建一套欠缺的监控体系，确保每一个环节都有相干指标上报，当出现异常（包含但不限于性能问题）时，可能通过相干监控指标疾速定位性能瓶颈，并制订相应解决方案。

Pulsar/BookKeeper 都提供了 Prometheus 接口，相干统计指标能够间接应用 Http 形式获取并间接对接 Prometheus/Grafana。感兴趣的同学能够间接依照 Pulsar Manager 的领导进行装置: https://github.com/streamnati…。

须要重点关注的指标如下：

  1. Pulsar Broker

    • jvm heap/gc
    • bytes in per broker
    • message in per broker
    • loadbalance
    • broker 端 Cache 命中率
    • bookie client quarantine ratio
    • bookie client request queue

  2. BookKeeper

    • bookie request queue size
    • bookie request queue wait time
    • add entry 99th latency
    • read entry 99th latency
    • journal create log latency
    • ledger write cache flush latency
    • entry read throttle

  3. ZooKeeper

    • local/global ZooKeeper read/write request latency

有一些指标在下面 repo 中没有提供相应 Grafana 模板，大家能够本人增加 PromQL 进行配置。

Pulsar broker 端性能调优

对 Pulsar broker 的性能调优，次要分为如下几个方面：

  1. 负载平衡

    • Broker 之间负载平衡
    • Bookie 节点之间的负载平衡

  2. 限流

    • Broker 接管音讯须要做流控，避免突发洪峰流量导致 broker direct memory OOM。
    • Broker 发送音讯给 consumer/reader 时须要做流控，避免一次发送太多音讯造成 consumer/reader 频繁 GC。
  3. 进步 Cache 命中率
  4. 保障 ZooKeeper 读写低提早
  5. 敞开 auto bundle split，保证系统稳固

负载平衡

Broker 之间负载平衡

Broker 之间负载平衡，可能进步 broker 节点的利用率，进步 Broker Cache 命中率，升高 broker OOM 概率。这一部分内容次要波及到 Pulsar bundle rebalance 相干常识。

Namespace Bundle 构造如下，每个 namespace（命名空间）由肯定数量的 bundle 组成，该 namespace 下的所有 topic 均通过 hash 形式映射到惟一 bundle 上，而后 bundle 通过 load/unload 形式加载 / 卸载到提供服务的 broker 上。

如果某个 broker 上没有 bundle 或者 bundle 数量比其余 broker 少，那么这台 broker 的流量就会比其余 broker 低。

现有的 / 默认的 bundle rebalance 策略（OverloadShedder）为：每隔一分钟统计集群中所有 broker 的 CPU、Memory、Direct Memory、BindWith In、BindWith Out 占用率的最大值是否超过阈值（默认为 85%）；如果超过阈值，则将肯定数量大入流量的 bundle 从该 broker 中卸载掉，而后由 leader 决定将被卸载掉的 bundle 从新加载到负载最低的 broker 上。

这个策略存在的问题是：

  1. 默认阈值比拟难达到，很容易导致集群中大部分流量都集中在几个 broker 上；
  2. 阈值调整规范难以确定，受其余因素影响较大，特地是这个节点上部署有其余服务的状况下；
  3. broker 重启后，长时间没有流量平衡到该 broker 上，因为其余 broker 节点均没有达到 bundle unload 阈值。

为此，咱们开发了一个基于均值的负载平衡策略，并反对 CPU、Memory、Direct Memory、BindWith In、BindWith Out 权重配置，相干策略请参见 PR-6772。

该策略在 Pulsar 2.6.0 版本开始反对，默认敞开，能够在 broker.conf 中批改如下参数开启：

loadBalancerLoadSheddingStrategy=org.apache.pulsar.broker.loadbalance.impl.ThresholdShedder

咱们能够通过如下参数来准确管制不同采集指标的权重：

# The broker resource usage threshold.
# When the broker resource usage is greater than the pulsar cluster average resource usage,
# the threshold shredder will be triggered to offload bundles from the broker.
# It only takes effect in ThresholdSheddler strategy.
loadBalancerBrokerThresholdShedderPercentage=10

# When calculating new resource usage, the history usage accounts for.
# It only takes effect in ThresholdSheddler strategy.
loadBalancerHistoryResourcePercentage=0.9
# The BandWithIn usage weight when calculating new resource usage.
# It only takes effect in ThresholdShedder strategy.
loadBalancerBandwithInResourceWeight=1.0

# The BandWithOut usage weight when calculating new resource usage.
# It only takes effect in ThresholdShedder strategy.
loadBalancerBandwithOutResourceWeight=1.0

# The CPU usage weight when calculating new resource usage.
# It only takes effect in ThresholdShedder strategy.
loadBalancerCPUResourceWeight=1.0

# The heap memory usage weight when calculating new resource usage.
# It only takes effect in ThresholdShedder strategy.
loadBalancerMemoryResourceWeight=1.0

# The direct memory usage weight when calculating new resource usage.
# It only takes effect in ThresholdShedder strategy.
loadBalancerDirectMemoryResourceWeight=1.0

# Bundle unload minimum throughput threshold (MB), avoiding bundle unload frequently.
# It only takes effect in ThresholdShedder strategy.
loadBalancerBundleUnloadMinThroughputThreshold=10

平衡 bookie 节点之间的负载

Bookie 节点负载监控如下图所示，咱们会发现：

  1. Bookie 节点之间负载并不是平均的，最高流量节点和最低流量节点可能相差几百 MB/s
  2. 在高负载状况下，某些节点的负载可能会呈现周期性上涨和降落，周期为 30 分钟

这些问题的影响是：bookie 负载不平衡，导致 BookKeeper 集群利用率降落，且容易呈现抖动。

呈现这个问题的起因在于：bookie client 对 bookie 写申请的熔断策略粒度太大。

先来回顾一下 Pulsar broker 写入 bookie 的策略：

当 broker 接管到 producer 发送的 message 时，首先会将音讯寄存在 broker 的 direct memory 中，而后调用 bookie client 依据配置的（EnsembleSize,WriteQuorum,AckQuorum）策略将 message 以 pipeline 形式发送给 bookies。

Bookie client 每分钟会统计各 bookie 写入的失败率（包含写超时等各类异样）。默认状况下，当失败率超过 5 次 / 分钟时，这台 bookie 将会被关入小黑屋 30 分钟，防止继续向出现异常的 bookie 写入数据，从而保障 message 写入成功率。

这个熔断策略存在的问题是：某台 bookie 负载（流量）很高时，所有写入到该 bookie 的音讯有可能同时会变慢，所有 bookie client 可能同时收到写入异样，如写入超时等，那么所有 bookie client 会同时把这台 bookie 关入小黑屋 30 分钟，等到 30 分钟之后又同时退出可写入列表中。这就导致了这台 bookie 的负载周期性上涨和降落。

为了解决该问题，咱们引入了基于概率的 quarantine 机制，当 bookie client 写入音讯出现异常时，并不是间接将这台 bookie 关入小黑屋，而是基于概率决定是否 quarantine。

这一 quarantine 策略能够防止所有 bookie client 同时将同一台 bookie 关入小黑屋，防止 bookie 入流量抖动。相干 PR 请参见：BookKeeper PR-2327，因为代码没有合并和公布到 bookie 主版本，大家如果想应用该性能，须要本人独立编译代码：https://github.com/apache/boo…。


从 BIGO 实际测试来看，该性能将 bookie 节点之间入流量标准差从 75 MB/s 升高到 40 MB/s。

限流

>>Broker direct memory OOM（内存溢出）

在生产环境中，在高吞吐场景下，咱们常常遇到 broker direct memory OOM，导致 broker 过程挂掉。这里的起因可能是底层 bookie 写入变慢，导致大量数据积压在 broker direct memory 中。Producer 发送的音讯在 broker 中的处理过程如下图所示：

在生产环境中，咱们不能保障底层 bookie 始终保持非常低的写提早，所以须要在 broker 层做限流。Pulsar 社区的鹏辉开发了限流性能，限流逻辑如下图所示：

在 Pulsar 2.5.1 版本中已公布，请参见 PR-6178。

Consumer 耗费大量内存

当 producer 端以 batch 模式发送音讯时，consumer 端往往会占用过多内存导致频繁 GC，监控上的体现是：这个 topic 的负载在 consumer 启动时飙升，而后逐步回归到失常程度。

这个问题的起因须要联合 consumer 端的生产模式来看。

当 consumer 调用 receive 接口生产一条音讯时，它会间接从本地的 receiverQueue 中申请一条音讯，如果 receiverQueue 中还有音讯能够获取，则间接将音讯返回给 consumer 端，并更新 availablePermit，当 availablePermit < receiverQueueSize/2 时，Pulsar client 会将 availablePermit 发送给 broker，通知 broker 须要 push 多少条音讯过去；如果 receiverQueue 中没有音讯能够获取，则期待 / 返回失败，直到 receiverQueue 收到 broker 推送的音讯才将 consumer 唤醒。

Broker 收到 availablePermit 之后，会从 broker Cache/bookie 中读取 max(availablePermit, batchSize) 条 entry，并发送给 consumer 端。解决逻辑如下图所示:

这里的问题是：当 producer 开启 batch 模式发送，一个 entry 蕴含多条音讯，然而 broker 解决 availablePermit 申请依然把一条音讯作为一个 entry 来解决，从而导致 broker 一次性将大量信息发送给 consumer，这些音讯数量远远超过 availiablePermit（availiablePermit vs. availiablePermit * batchSize）的承受能力，引起 consumer 占用内存暴涨，引发频繁 GC，升高生产性能。

为了解决 consumer 端内存暴涨问题，咱们在 broker 端统计每个 topic 均匀 entry 蕴含的音讯数（avgMessageSizePerEntry），当接管到 consumer 申请的 availablePermit 时，将其换算成须要发送的 entry 大小，而后从 broker Cache/bookie 中拉取相应数量的 entry，而后发送给 consumer。解决逻辑如下图所示：

这个性能在 Pulsar 2.6.0 中已公布，默认是敞开的，大家能够通过如下开关启用该性能：

# Precise dispatcher flow control according to history message number of each entry
preciseDispatcherFlowControl=true

进步 Cache 命中率

Pulsar 中有多层 Cache 晋升 message 的读性能，次要包含：

  • Broker Cache
  • Bookie write Cache(Memtable)
  • Bookie read Cache
  • OS PageCache

本章次要介绍 broker Cache 的运行机制和调优计划，bookie 侧的 Cache 调优放在下篇介绍。

当 broker 收到 producer 发送给某个 topic 的音讯时，首先会判断该 topic 是否有 Active Cursor，如果有，则将收到的音讯写入该 topic 对应的 Cache 中；否则，不写入 Cache。解决流程如下图所示：


判断是否有 Active Cursor 须要同时满足以下两个条件：

  1. 有 durable cursor
  2. Cursor 的 lag 在 managedLedgerCursorBackloggedThreshold 范畴内

因为 reader 应用 non-durable cursor 进行生产，所以 producer 写入的音讯不会进入 broker Cache，从而导致大量申请落到 bookie 上，性能有所损耗。

streamnative/pulsar-flink-connector 应用的是 reader API 进行生产，所以同样存在生产性能低的问题。

咱们 BIGO 音讯队列团队的赵荣生同学修复了这个问题，将 durable cursor 从 Active Cursor 判断条件中删除，详情请见 PR-6769，这个 feature 在 Pulsar 2.5.2 公布，有遇到相干性能问题的同学请降级 Pulsar 版本到 2.5.2 以上。

此外，咱们针对 topic 的每个 subscription 增加了 Cache 命中率监控，不便进行生产性能问题定位，后续会奉献到社区。

Tailing Read

对于曾经在 broker Cache 中的数据，在 tailing read 场景下，咱们怎么进步 Cache 命中率，升高从 bookie 读取数据的概率呢？咱们的思路是尽可能让数据从 broker Cache 中读取，为了保障这一点，咱们从两个中央着手优化：

  1. 管制断定为 Active Cursor 的最大 lag 范畴，默认是 1000 个 entry，由如下参数控:
# Configure the threshold (in number of entries) from where a cursor should be considered 'backlogged'
# and thus should be set as inactive.
managedLedgerCursorBackloggedThreshold=1000

Active Cursor 的断定如下图所示。

  1. 管制 broker Cache 的 eviction 策略，目前 Pulsar 中只反对默认 eviction 策略，有需要的同学能够自行扩大。默认 eviction 策略由如下参数管制：
# Amount of memory to use for caching data payload in managed ledger. This memory
# is allocated from JVM direct memory and it's shared across all the topics
# running  in the same broker. By default, uses 1/5th of available direct memory
managedLedgerCacheSizeMB=

# Whether we should make a copy of the entry payloads when inserting in cache
managedLedgerCacheCopyEntries=false

# Threshold to which bring down the cache level when eviction is triggered
managedLedgerCacheEvictionWatermark=0.9

# Configure the cache eviction frequency for the managed ledger cache (evictions/sec)
managedLedgerCacheEvictionFrequency=100.0

# All entries that have stayed in cache for more than the configured time, will be evicted
managedLedgerCacheEvictionTimeThresholdMillis=1000

Catchup Read

对于 Catchup Read 场景，broker Cache 大概率会失落，所有的 read 申请都会落到 bookie 上，那么有没有方法进步读 bookie 的性能呢？

Broker 向 bookie 批量发送读取申请，最大 batch 由 dispatcherMaxReadBatchSize 管制，默认是 100 个 entry。

# Max number of entries to read from bookkeeper. By default it is 100 entries.
dispatcherMaxReadBatchSize=100

一次读取的 batchSize 越大，底层 bookie 从磁盘读取的效率越高，均摊到单个 entry 的 read latency 就越低。然而如果过大也会造成 batch 读取提早减少，因为底层 bookie 读取操作时每次读一条 entry，而且是同步读取。

这一部分的读取调优放在《Apache Pulsar 在 BIGO 的性能调优实战（下）》中介绍。

保障 ZooKeeper 读写低提早

因为 Pulsar 和 BookKeeper 都是重大依赖 ZooKeeper 的，如果 ZooKeeper 读写提早减少，就会导致 Pulsar 服务不稳固。所以须要优先保障 ZooKeeper 读写低提早。倡议如下：

  1. 在磁盘为 HDD 状况下，ZooKeeper dataDir/dataLogDir 不要和其余耗费 IO 的服务（如 bookie Journal/Ledger 目录 ) 放在同一块盘上（SSD 除外）；
  2. ZooKeeper dataDir 和 dataLogDir 最好可能放在两块独立磁盘上（SSD 除外）；
  3. 监控 broker/bookie 网卡利用率，防止因为网卡打满而造成和 ZooKeeper 失联。

敞开 auto bundle split，保证系统稳固

Pulsar bundle split 是一个比拟消耗资源的操作，会造成连贯到这个 bundle 上的所有 producer/consumer/reader 连贯断开并重连。个别状况下，触发 auto bundle split 的起因是这个 bundle 的压力比拟大，须要切分成两个 bundle，将流量摊派到其余 broker，来升高这个 bundle 的压力。管制 auto bundle split 的参数如下：

# enable/disable namespace bundle auto split
loadBalancerAutoBundleSplitEnabled=true

# enable/disable automatic unloading of split bundles
loadBalancerAutoUnloadSplitBundlesEnabled=true

# maximum topics in a bundle, otherwise bundle split will be triggered
loadBalancerNamespaceBundleMaxTopics=1000

# maximum sessions (producers + consumers) in a bundle, otherwise bundle split will be triggered
loadBalancerNamespaceBundleMaxSessions=1000

# maximum msgRate (in + out) in a bundle, otherwise bundle split will be triggered
loadBalancerNamespaceBundleMaxMsgRate=30000

# maximum bandwidth (in + out) in a bundle, otherwise bundle split will be triggered
loadBalancerNamespaceBundleMaxBandwidthMbytes=100

当触发 auto bundle split 时 broker 负载比拟高，敞开这个 bundle 上的 producer/consumer/reader，连贯就会变慢，并且 bundle split 的耗时也会变长，就很容易造成 client 端（producer/consumer/reader）连贯超时而失败，触发 client 端主动重连，造成 Pulsar/Pulsar client 不稳固。

对于生产环境，咱们的倡议是：事后为每个 namespace 调配好 bundle 数，并敞开 auto bundle split 性能。如果在运行过程中发现某个 bundle 压力过大，能够在流量低峰期进行手动 bundle split，升高对 client 端的影响。

对于事后调配的 bundle 数量不宜太大，bundle 数太多会给 ZooKeeper 造成比拟大的压力，因为每一个 bundle 都要定期向 ZooKeeper 汇报本身的统计数据。

总结

本篇从性能调优角度介绍了 Pulsar 在 BIGO 实际中的优化计划，次要分为环境部署、流量平衡、限流措施、进步 Cache 命中率、保障 Pulsar 稳定性等 5 个方面，并深刻介绍了 BIGO 音讯队列团队在进行 Pulsar 生产落地过程中的一些教训。

本篇次要解决了开篇提到的这几个问题（1、2、5、7、8、9）。对于问题 3，咱们提出了一个缓解计划，但并没有指出 Pulsar broker OOM 的根本原因，这个问题须要从 BookKeeper 角度来解决，剩下的问题都和 BookKeeper 相干。

因为 Pulsar 应用分层存储架构，底层的 BookKeeper 仍须要进行一系列调优来配合下层 Pulsar，充分发挥高吞吐、低提早性能；下篇将从 BookKeeper 性能调优角度介绍 BIGO 的实践经验。

非常感谢 StreamNative 同学的悉心领导和自私帮忙，让 Pulsar 在 BIGO 落地迈出了松软的一步。Apache Pulsar 提供的高吞吐、低提早、高可靠性等个性极大进步了 BIGO 音讯解决能力，升高了音讯队列运维老本，节约了近一半的硬件老本。

同时，咱们也踊跃融入 Pulsar 社区，并将相干成绩奉献回社区。咱们在 Pulsar Broker 负载平衡、Broker Cache 命中率优化、Broker 相干监控、Bookkeeper 读写性能优、Bookkeeper 磁盘 IO 性能优化、Pulsar 与 Flink & Flink SQL 联合等方面做了大量工作，帮忙社区进一步优化、欠缺 Pulsar 性能。

对于作者

陈航，BIGO 大数据音讯平台团队负责人，负责承载大规模服务与利用的集中公布 - 订阅音讯平台的创立与开发。他将 Apache Pulsar 引入到 BIGO 音讯平台，并买通上下游零碎，如 Flink、ClickHouse 和其余实时举荐与剖析零碎。他目前聚焦 Pulsar 性能调优、新性能开发及 Pulsar 生态集成方向。

退出移动版