Kafka-streams：為什么所有分區都分配給使用者組中的同一使用者？

Question

背景

多台機器生成事件。 這些事件將發送到我們的Kafka集群，其中每台機器都有自己的主題（app.machine-events。machine -name ）。 因為順序對於每台計算機而言很重要，並且分區大小現在不是問題，所以所有主題都由一個分區組成。 因此，當前N個主題也意味着N個分區。

消費/處理應用程序利用kafka-streams，我們為它提供了StreamsConfig.APPLICATION_ID_CONFIG / "application.id" 'machine-event-processor'，對於每個實例它都保持不變，這意味着它們被放入同一實例中卡夫卡的消費群體。 該使用者已訂閱模式app.machine-events.* ，因為對於處理器，它處理的是哪個機器的事件都沒有關系。 這已經通過./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group machine-event-processor --members --verbose顯示了一個與所有IP數量匹配的列表處理服務正在運行。

預期

給定20台計算機和5個處理器實例，我們希望每個處理器處理約4個分區（因此約有4個主題）。

其實

有一個處理器處理20個分區（因此有20個主題），而其他4個處理器則完全不執行任何操作/空閑。 殺死“幸運”處理器后，所有20個分區都重新平衡到另一個處理器，導致新處理器處理20個分區/主題，並使3個處理器空閑。

到目前為止我嘗試過的

• 檢出partition.grouper 。 我覺得我不太了解，但是據我所知，仍然只有DefaultPartitioner選項，並且（根據文檔）不必編寫自定義選項，因為此設置可以正常工作。 它確實提到了分區是基於分區鍵（對於我們來說都是0，因為每個主題只有一個分區）加入到任務中，但是我無法完全理解這一部分。
• 供使用者使用的RoundRobinAssignor： settings.put(StreamsConfig.consumerPrefix(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG), new RoundRobinAssignor().getClass.getName) （嘗試了多個值，因為似乎沒有什么變化。）
• 查看其他配置屬性 ，以查看是否遺漏了一些東西：我認為沒有。

代碼，簡化

val streamConfig = new Properties
// {producer.metadata.max.age.ms=5000, consumer.metadata.max.age.ms=5000, default.key.serde=org.apache.kafka.common.serialization.Serdes$StringSerde, consumer.partition.assignment.strategy=org.apache.kafka.clients.consumer.RoundRobinAssignor, bootstrap.servers=kafka:9092, application.id=machine-event-processor, default.value.serde=org.apache.kafka.common.serialization.Serdes$ByteArraySerde}
val builder: StreamsBuilder = new StreamsBuilder
val topicStream: KStream[String, Array[Byte]] = builder.stream(Pattern.compile("app.machine-events.*"))
topicStream.process(new MessageProcessorSupplier(context)) // The event is delegated to a processor, doing the actual processing logic
val eventStreams = new KafkaStreams(builder.build(), streamConfig)
eventStreams.start()

筆記

• 使用Kafka-streams 2.0.0：

  <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-streams</artifactId> <version>2.0.0</version> </dependency>

• Kafka正在使用wurstmeister/kafka:2.11-2.0.0版本在容器內運行。 docker-stack.yml服務：

kafka: image: wurstmeister/kafka:2.11-2.0.0 ports: - target: 9094 published: 9094 protocol: tcp mode: host volumes: - /var/run/docker.sock:/var/run/docker.sock healthcheck: test: ["CMD-SHELL", "$$(netstat -ltn | grep -q 9092)"] interval: 15s timeout: 10s retries: 5 environment: HOSTNAME_COMMAND: "docker info | grep ^Name: | cut -d' ' -f 2" KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_ZOOKEEPER_CONNECTION_TIMEOUT_MS: 36000 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: INSIDE:PLAINTEXT,OUTSIDE:PLAINTEXT KAFKA_ADVERTISED_LISTENERS: INSIDE://:9092,OUTSIDE://_{HOSTNAME_COMMAND}:9094 KAFKA_LISTENERS: INSIDE://:9092,OUTSIDE://:9094 KAFKA_INTER_BROKER_LISTENER_NAME: INSIDE KAFKA_DEFAULT_REPLICATION_FACTOR: 2 deploy: replicas: 2 restart_policy: condition: on-failure delay: 5s max_attempts: 3 window: 120s

• Kafka是在雙節點設置中設置的，形成一個集群。 通過docker環境變量，我們將復制因子設置為2 ，因此每個分區應該在每個節點上都有一個復制。

我找到並檢查過的相關主題/問題/討論

• KIP-49

• https://faust.readthedocs.io/en/latest/developerguide/partition_assignor.html

• 檢查了Kafka 郵件檔案，但沒有找到任何東西

• 簽出流示例應用

• 全面搜索遇到此問題的其他人，但沒有給我我所需的答案。 還發現了KAFKA-7144，但這對我們來說不是問題，因為我們正在運行2.0.0

如果有人遇到類似問題，或者能夠指出我可能非常愚蠢的錯誤，請賜教！

Answer 1

對於將來遇到此問題的讀者，解決方案是不使用每個都有1個分區的N個主題，而使用帶有N個分區的1個主題。 即使有120個分區和400多個計算機/事件源，也將多個事件類型放入同一個分區，但這不會影響事件的順序。

實現是將記錄鍵設置為計算機名稱，並讓底層邏輯負責將哪個值分配給哪個分區。 由於我們現在有一個消費者組，其中有X個消費者訂閱了該主題，因此分區在消費者上平均分配，每個分區有120 / X個分區。

正如Matthias所建議的那樣，Confluent的其他樂於助人的人在Devoxx Belgium 2018上進一步證實了這一點。謝謝！

小費

使用wurstmeister / kafka docker映像時，請考慮使用environment屬性：

KAFKA_CREATE_TOPICS：“ app.machine-events：120：2”

含義

主題名稱：數的-分區：復制因子