推荐一款非常好用的kafka管理平台,kafka的灵魂伴侣

滴滴开源Logi-KafkaManager 一站式Kafka监控与管控平台

项目地址: didi/Logi-KafkaManager: 一站式Apache Kafka集群指标监控与运维管控平台

专家服务

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

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=310241024
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 = 3*1024*1024
  "minTopicBytesInUnitB": 3145728,//Topic的近一分钟的(btyesIn B/s)值 要大于这个值; 默认是  3M = 3*1024*1024
  "ignoreClusterIdList": [  //忽略指定的物理集群; 默认空
    0,
    1
  ]
}

判定逻辑伪代码

for(遍历所有Topic){

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

	if(ignoreClusterIdList){
		忽略
	}
	
	if(BytesInPerSecOneMinuteRate <= minTopicBytesInUnitB){
		忽略
	}
	
	if(BytesInPerSecOneMinuteRate / topic的总分区数 < maxBytesInPerPartitionUnitB){
		忽略
	}
    return  topic分区热点;
}

Topic资源治理

功能不全,待开发

异常诊断

功能不全,待开发

滴滴开源Logi-KafkaManager 一站式Kafka监控与管控平台