赞
踩
kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic aaa --time 1612108800000
./kafka-topics.sh --list --zookeeper 172.18.153.12:2188
./kafka-topics.sh --describe --zookeeper 172.18.153.12:2188 --topic test
./kafka-run-class.sh kafka.tools.GetOffsetShell --topic test --time -1 --broker-list 10.1.3.84:9098 --partitions 0
./kafka-topics.sh --zookeeper 172.18.153.12:2188 --alter --topic test --partitions 10
方法一:
./kafka-topics.sh --delete --zookeeper 172.18.153.12:2188 --topic test
方法二:待验证
./kafka-run-class.sh kafka.admin.DeleteTopicCommand --zookeeper 172.18.153.12:2188 --topic test
./kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper localhost:2181 --group group1
./kafka-consumer-groups.sh --bootstrap-server 10.1.3.84:9098 --list
./kafka-consumer-groups.sh --bootstrap-server 10.1.3.84:9098 --describe --group group1
./kafka-consumer-groups.sh --bootstrap-server 10.1.3.84:9098 --describe --group group1 --members
消息堆积是消费滞后(Lag)的一种表现形式,消息中间件服务端中所留存的消息与消费掉的消息之间的差值即为消息堆积量,也称之为消费滞后(Lag)量。
对于Kafka而言,消息被发送至Topic中,而Topic又分成了多个分区(Partition),每一个Partition都有一个预写式的日志文件,虽然Partition可以继续细分为若干个段文件(Segment),但是对于上层应用来说可以将Partition看成最小的存储单元(一个由多个Segment文件拼接的“巨型文件”)。
每个Partition都由一系列有序的、不可变的消息组成,这些消息被连续的追加到Partition中。我们来看下图,其就是Partition的一个真实写照:
上图中有四个概念:
LogStartOffset:表示一个Partition的起始位移,初始为0,虽然消息的增加以及日志清除策略的影响,这个值会阶段性的增大。
ConsumerOffset:消费位移,表示Partition的某个消费者消费到的位移位置。
HighWatermark:简称HW,代表消费端所能“观察”到的Partition的最高日志位移,HW大于等于ConsumerOffset的值。
LogEndOffset:简称LEO, 代表Partition的最高日志位移,其值对消费者不可见。
比如在ISR(In-Sync-Replicas)副本数等于3的情况下(如下图所示),消息发送到Leader A之后会更新LEO的值,Follower B和Follower C也会实时拉取Leader A中的消息来更新自己,HW就表示A、B、C三者同时达到的日志位移,也就是A、B、C三者中LEO最小的那个值。由于B、C拉取A消息之间延时问题,所以HW必然不会一直与Leader的LEO相等,即LEO>=HW。
要计算Kafka中某个消费者的滞后量很简单,首先看看其消费了几个Topic,然后针对每个Topic来计算其中每个Partition的Lag,每个Partition的Lag计算就显得非常的简单了,参考下图:
由图可知消费Lag=HW - ConsumerOffset。Kafka中自带的kafka-consumer_groups.sh脚本中就有Lag的信息,示例如下:
[root@node2 kafka_2.12-1.0.0]# bin/kafka-consumer-groups.sh --describe --bootstrap-server localhost:9092 --group CONSUMER_GROUP_ID
TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
topic-test1 0 1648 1648 0 CLIENT_ID-e2d41f8d-dbd2-4f0e-9239-efacb55c6261 /192.168.92.1 CLIENT_ID
topic-test1 1 1648 1648 0 CLIENT_ID-e2d41f8d-dbd2-4f0e-9239-efacb55c6261 /192.168.92.1 CLIENT_ID
topic-test1 2 1648 1648 0 CLIENT_ID-e2d41f8d-dbd2-4f0e-9239-efacb55c6261 /192.168.92.1 CLIENT_ID
topic-test1 3 1648 1648 0 CLIENT_ID-e2d41f8d-dbd2-4f0e-9239-efacb55c6261 /192.168.92.1 CLIENT_ID
参考:
Kafka的Lag计算误区及正确实现:https://blog.csdn.net/u013256816/article/details/79955578
如何使用JMX监控Kafka:https://blog.csdn.net/u013256816/article/details/53524884
作者:chen_chen_chen_
链接:https://www.jianshu.com/p/9f1114ee8ecd
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。