Kafka的灵魂伴侣Logi-KafkaManger(6)之专家服务(分区热点分区不足)

专家服务

====================================================================

直观的展示和分析当前被管理的集群中出现的问题; 以及可视化运维

Topic分区热点

---

看到这个词,我们可以先想一想 什么是分区热点,什么情况下会出现分区热点情况;

按照我的理解,我将其罗列为以下几点

什么是分区热点

1. Topic分区上数据分配不均衡

造成的原因: 当生产者指定了分区数 或者key的时候, 有可能造成某个分区的消息生产速率远远大于其他分区

2. 分区Leader在多个集群中分配不均

造成的原因:多个Broker宕机,导致宕机的Broker上的分区Leader转移到其他Broker上,恢复之后也没有触发 Leader Rebalance, 就会导致,某些Topic的分区Leader分配不均匀;

还有就是新增了很多Broker,某些原因造成新的Broker没有分配到Leader, 又或者把其他分区迁移到了别的 分区等等都会造成这样的问题;

上面的第一种,属于业务逻辑上的热点,我们没法控制,

但是第二种情况可以算作是集群异常点了, 需要我们重新去重新做一下 Leader Rebalance

那么意思是不是只要做一下 Leader Rebalance就解决了？像其他问题导致优先副本本身就不均衡,你再LR也没有用

所以更好的解决办法就是做一下数据迁移;

KM解决分区热点问题

KM判断分区热点逻辑

平台配置

KEY:REGION_HOT_TOPIC_CONFIG

VALUE:

minTopicBytesInUnitB: Topic最近一分钟的每秒评价流量 的阈值 默认3M=3_1024_1024

maxDisPartitionNum: Broker直接最大的分区数差值

ignoreClusterIdList: 忽略的物理集群ID

判断逻辑

还有一个判断逻辑是 maxDisPartitionNum: Broker直接最大的分区数差值 ;

像下面的这种分配情况,2-0=2; 如果你的配置 maxDisPartitionNum=1 那么肯定就满足了条件了

KM 解决分区热点–数据迁移

这里的迁移任务跟 Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁移和集群在线升级) 是一样的; 这里就不讲解了,不过这里选择的目标BrokerID是默认当前Topic所归属的所有Region下的所有Broker; (相当于把分区在选择的Broker中重新分配了一下)

Topic分区不足

---

按照一定的规则,来判断是否分区不足, 主要就是计算一下 Topic最近一分钟的平均流量值 / 分区数 是否超过某个阈值(阈值可以自定义);

自定义阈值

首先可以在平台配置那里自定义 判断的条件限定值; (不设置也可以,有默认值)

KEY： TOPIC_INSUFFICIENT_PARTITION_CONFIG

VALUE:

{

“maxBytesInPerPartitionUnitB”: 3145728,//每个分区近一分钟的(btyesIn B/s)的最大值 默认是 3M = 310241024

“minTopicBytesInUnitB”: 3145728,//Topic的近一分钟的(btyesIn B/s)值 要大于这个值; 默认是 3M = 310241024

“ignoreClusterIdList”: [ //忽略指定的物理集群; 默认空

0,

1

]

}

判定逻辑伪代码

for(遍历所有Topic){

//（BytesInPerSecOneMinuteRate 表示最近一分钟Topic流入的byteIn(KB/s)值;）

if(ignoreClusterIdList){

忽略

}

if(BytesInPerSecOneMinuteRate <= minTopicBytesInUnitB){

忽略

}

if(BytesInPerSecOneMinuteRate / topic的总分区数 < maxBytesInPerPartitionUnitB){

忽略

}

return topic分区热点;

}

Topic资源治理

---

功能不全,待开发