我有一个主题在Kafka描述如下(通过 /usr/hdp/2.6.5.0-292/kafka/bin/kafka-topics.sh --describe <rest of command>
)
Topic:arrival_events PartitionCount:12 ReplicationFactor:2 Configs:
Topic: arrival_events Partition: 0 Leader: 1001 Replicas: 1001,1002 Isr: 1001,1002
Topic: arrival_events Partition: 1 Leader: 1002 Replicas: 1002,1003 Isr: 1002,1003
Topic: arrival_events Partition: 2 Leader: 1003 Replicas: 1003,1001 Isr: 1003,1001
Topic: arrival_events Partition: 3 Leader: 1001 Replicas: 1001,1003 Isr: 1003,1001
Topic: arrival_events Partition: 4 Leader: 1002 Replicas: 1002,1001 Isr: 1002,1001
Topic: arrival_events Partition: 5 Leader: 1003 Replicas: 1003,1002 Isr: 1003,1002
Topic: arrival_events Partition: 6 Leader: 1001 Replicas: 1001,1002 Isr: 1001,1002
Topic: arrival_events Partition: 7 Leader: 1002 Replicas: 1002,1003 Isr: 1002,1003
Topic: arrival_events Partition: 8 Leader: 1003 Replicas: 1003,1001 Isr: 1003,1001
Topic: arrival_events Partition: 9 Leader: 1001 Replicas: 1001,1003 Isr: 1003,1001
Topic: arrival_events Partition: 10 Leader: 1002 Replicas: 1002,1001 Isr: 1002,1001
Topic: arrival_events Partition: 11 Leader: 1003 Replicas: 1003,1002 Isr: 1003,1002
经纪人大致收到 5-8mil
每天的信息(旅行模式)。
一切都很好,除了几个分区(不超过2-3个)被高延迟阻塞。
随着数据的连续流动,在几天内,这有时也会超过1-2英里。而其他分区舒适地位于0滞后
我已经试着把消费者人数降到12人以下 round robin
也会强制读取其他分区,但没有帮助。
我有什么办法来减少这个滞后的建议吗?消费者通过使用java构建的数据流处理器。
1条答案
按热度按时间hpxqektj1#
如果消息具有非空的消息键,那么可能具有高延迟的分区比其他分区获得更多的数据。在这种情况下,如果强制执行循环分区方案对业务逻辑没有任何影响,那么不管密钥是什么,都可能是有益的。