构建下一代万亿级云原生消息架构：Apache Pulsar 在 vivo 的探索与实践( 四 ) 作者|陈建波、全利民本文整理

在实际使用中，如果机器节点的磁盘较小且数据迟迟得不到删除，为了及时清除数据，应该按照业务流量和磁盘空间适当调整数据清理间隔时间、有效数据阈值，并配合compaction限速策略减小对集群的影响。
3Pulsar监控实践
vivo的Pulsar指标监控链路架构如下：

文章图片
图10.vivo针对Pulsar监控指标搭建的监控架构
该架构中：采用Prometheus采集Pulsar指标；应用Prometheus远程存储特性将格式化后的指标发送到Kafka；Druid消费Kafka数据后可以作为Grafana的数据源，配置Grafana面板查询指标。
为什么不使用Prometheus存储数据？因为有些数据较久远，一旦集群规模增加，监控指标数量级会很大。 Prometheus对资源依赖重，我们只采用了它的采集能力。
下图是常用的关键指标：

文章图片
图11.关键监控指标
指标类型分为：客户端指标：用来排查客户端出现的异常Broker端指标：监控topic流量、调整broker间流量差距Bookie端指标：排查读写延迟等问题
除了官方指标外，团队还开发了Bundle相关的一些指标：分区数、流量等在Bundle的分布Broker端记录读写延迟的P95/P99值基于请求对列实现Broker端网络负载指标等。
4问题优化与最佳实践
负载均衡参数
负载均衡的目的是对资源平均分配，差异大会影响稳定性。对负载均衡设置的目标是节点流量偏差20%以内，每天均衡频次在10次以内，否则客户端会频繁断连、重连。优化后的参数如下：#loadsheddingstrategy,supportOverloadShedderandThresholdShedder,defaultisOverloadShedderloadBalancerLoadSheddingStrategy=org.apache.pulsar.Broker.loadbalance.impl.ThresholdShedder
#enable/disablenamespaceBundleautosplitloadBalancerAutoBundleSplitEnabled=false
#enable/disableautomaticunloadingofsplitBundlesloadBalancerAutoUnloadSplitBundlesEnabled=false
#计算新资源使用量时的CPU使用权重（默认1.0）loadBalancerCPUResourceWeight=0.0
#计算新的资源使用量时的堆内存使用权重（默认1.0）loadBalancerMemoryResourceWeight=0.0
#计算新资源使用量时的直接内存使用权重（默认1.0）loadBalancerDirectMemoryResourceWeight=0.0
下面三个参数改为零，是因为集群使用了相同的机型，团队更关注流量均衡，对内存和CPU不是特别关注。
以一个具体产品案例来看，其中有1个Topic、30个分区、180个Bundle：

文章图片
图12.1个Topic、30个分区、180个Bundle的每秒入流量
上图节点间流量差异较大，由Bundleunload导致。

文章图片
图13.1个Topic、30个分区、180个Bundle下， Bundle上Topic分区情况
上图可看出，有两个Bundle分配了四个分区，远超其他Bundle 。实践中出现以下问题：均衡频次高，一天大概有200多次客户端连接频繁切换，流量波动大每个Bundle的分区数量分布差异大

文章图片
图14.1个Topic、30个分区、180个Bundle的入流量分布
优化过程中，关键在于将分区打散到不同Bundle上，但分区数量太少很难做到。 Topic通过哈希算法分配到Bundle上在前文已经介绍。此案例中，问题在于分区数量少。
于是团队将分区增加到120个，效果如下：节点间流量差异小均衡频次降低，一天大概有10次左右客户端连接切换减少，流量波动较小每个bundle的分区数量分布差异降低