情景:
./kafka-topics.sh --alter --zookeeper zookeeper:2181 --topic test --partitions 100
我执行了几次这些步骤,看起来每隔约5分钟重新分配一次。
修改
我的用例如下:我们有集成测试来启动我们的微服务。当主题的使用者首先引导时,如果主题不存在,则创建该主题,并且它创建的分区数等于配置的concurrency
(例如10)。然后,该主题的生产者启动并且他配置的partitonCount
(例如20)大于创建的分区数,因此spring-cloud-stream添加了丢失的分区,同时消费者分配了分区,避风港没有改变,它从前10个分区(1-10)继续消耗。问题是生产者正在向所有20个分区发布消息,因此在为消费者分配新分区之前,不会消耗发送到最后10个分区(11-20)的消息。
这种行为导致我们的测试出现问题,我们不能等待5分钟,直到所有分区都分配给消费者。此外,我们不希望事先创建具有所需分区数量的主题,我们希望它仍然可以由spring-cloud-stream处理。
编辑2:
似乎控制“重新分配”的相关属性是metadata.max.age.ms
。
我们强制刷新元数据的时间段(以毫秒为单位),即使我们没有看到任何分区领导层更改以主动发现任何新的代理或分区。
答案 0 :(得分:2)
所以这里有几个问题。
首先," spring-cloud-stream"和/或" spring-kafka"没有做任何类型的重新平衡,分区重新分配等。这都是在Kafka内部完成的。 Kafka有一个客户端属性默认为5分钟(我相信),如果消费者没有轮询很长时间,认为它已经死了等等。无论如何我会推荐你apache-kafka频道获取有关Kafka内部的更多信息。
此外,添加分区,重新分配和重新平衡是昂贵的操作,如果不认真考虑其影响,则不应尝试。所以,我很想知道你不断添加分区的用例是什么?