docker容器中运行的kafka控制台使用者停止使用消息

docker容器中运行的kafka控制台使用者停止使用消息,docker,apache-kafka,docker-compose,confluent-platform,Docker,Apache Kafka,Docker Compose,Confluent Platform,我有合流的卡夫卡(v4.0.0)经纪人和3名动物园管理员。创建了一个测试主题,其中包含10个复制因子为3的分区。 当创建控制台使用者时,不使用passing--group选项(其中group.id将自动分配),即使在代理被终止并且代理重新联机之后,它也可以继续使用消息 但是,如果我使用--group选项('console-group')创建一个控制台使用者,那么消息消费将在kafka代理被终止后停止 $ docker run --net=host confluentinc/cp-kafka:4.

我有合流的卡夫卡(v4.0.0)经纪人和3名动物园管理员。创建了一个测试主题,其中包含10个复制因子为3的分区。 当创建控制台使用者时,不使用passing--group选项(其中group.id将自动分配),即使在代理被终止并且代理重新联机之后,它也可以继续使用消息

但是,如果我使用--group选项('console-group')创建一个控制台使用者,那么消息消费将在kafka代理被终止后停止

$ docker run --net=host confluentinc/cp-kafka:4.0.0 kafka-console-consumer --bootstrap-server localhost:19092,localhost:29092,localhost:39092 --topic starcom.status --from-beginning --group console-group
<< some messages consumed >>
<< broker got killed >> 
[2017-12-31 18:34:05,344] WARN [Consumer clientId=consumer-1, groupId=console-group] Connection to node -1 could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)
<< no message after this >> 
而且主题复制都正常进行

$ docker run --net=host confluentinc/cp-kafka:4.0.0 kafka-topics --zookeeper localhost:22181 --topic starcom.status --describe
Topic:starcom.status    PartitionCount:10       ReplicationFactor:3     Configs:
        Topic: starcom.status   Partition: 0    Leader: 3       Replicas: 3,1,2 Isr: 2,3,1
        Topic: starcom.status   Partition: 1    Leader: 1       Replicas: 1,2,3 Isr: 3,2,1
        Topic: starcom.status   Partition: 2    Leader: 2       Replicas: 2,3,1 Isr: 3,2,1
        Topic: starcom.status   Partition: 3    Leader: 3       Replicas: 3,2,1 Isr: 3,2,1
        Topic: starcom.status   Partition: 4    Leader: 1       Replicas: 1,3,2 Isr: 3,2,1
        Topic: starcom.status   Partition: 5    Leader: 2       Replicas: 2,1,3 Isr: 3,2,1
        Topic: starcom.status   Partition: 6    Leader: 3       Replicas: 3,1,2 Isr: 2,3,1
        Topic: starcom.status   Partition: 7    Leader: 1       Replicas: 1,2,3 Isr: 3,2,1
        Topic: starcom.status   Partition: 8    Leader: 2       Replicas: 2,3,1 Isr: 3,2,1
        Topic: starcom.status   Partition: 9    Leader: 3       Replicas: 3,2,1 Isr: 3,2,1

$ docker run --net=host confluentinc/cp-kafka:4.0.0 kafka-topics --zookeeper localhost:22181 --topic starcom.status --describe
Topic:starcom.status    PartitionCount:10       ReplicationFactor:3     Configs:
        Topic: starcom.status   Partition: 0    Leader: 3       Replicas: 3,1,2 Isr: 2,3
        Topic: starcom.status   Partition: 1    Leader: 2       Replicas: 1,2,3 Isr: 3,2
        Topic: starcom.status   Partition: 2    Leader: 2       Replicas: 2,3,1 Isr: 3,2
        Topic: starcom.status   Partition: 3    Leader: 3       Replicas: 3,2,1 Isr: 3,2
        Topic: starcom.status   Partition: 4    Leader: 3       Replicas: 1,3,2 Isr: 3,2
        Topic: starcom.status   Partition: 5    Leader: 2       Replicas: 2,1,3 Isr: 3,2
        Topic: starcom.status   Partition: 6    Leader: 3       Replicas: 3,1,2 Isr: 2,3
        Topic: starcom.status   Partition: 7    Leader: 2       Replicas: 1,2,3 Isr: 3,2
        Topic: starcom.status   Partition: 8    Leader: 2       Replicas: 2,3,1 Isr: 3,2
        Topic: starcom.status   Partition: 9    Leader: 3       Replicas: 3,2,1 Isr: 3,2

$ docker run --net=host confluentinc/cp-kafka:4.0.0 kafka-topics --zookeeper localhost:22181 --topic starcom.status --describe
Topic:starcom.status    PartitionCount:10       ReplicationFactor:3     Configs:
        Topic: starcom.status   Partition: 0    Leader: 3       Replicas: 3,1,2 Isr: 2,3,1
        Topic: starcom.status   Partition: 1    Leader: 1       Replicas: 1,2,3 Isr: 3,2,1
        Topic: starcom.status   Partition: 2    Leader: 2       Replicas: 2,3,1 Isr: 3,2,1
        Topic: starcom.status   Partition: 3    Leader: 3       Replicas: 3,2,1 Isr: 3,2,1
        Topic: starcom.status   Partition: 4    Leader: 1       Replicas: 1,3,2 Isr: 3,2,1
        Topic: starcom.status   Partition: 5    Leader: 2       Replicas: 2,1,3 Isr: 3,2,1
        Topic: starcom.status   Partition: 6    Leader: 3       Replicas: 3,1,2 Isr: 2,3,1
        Topic: starcom.status   Partition: 7    Leader: 1       Replicas: 1,2,3 Isr: 3,2,1
        Topic: starcom.status   Partition: 8    Leader: 2       Replicas: 2,3,1 Isr: 3,2,1
        Topic: starcom.status   Partition: 9    Leader: 3       Replicas: 3,2,1 Isr: 3,2,1
这是(合流的)卡夫卡控制台消费者的限制吗?基本上,我试图通过运行这个较小的测试来确保我真正的Java Kafka消费者能够在代理宕机后生存下来

任何帮助都将不胜感激

编辑(2018年!)

我完全重新创建了我的docker(-compose)环境,并能够复制它。这一次,我创建了“新组”使用者组,并且在代理重新启动后,控制台使用者抛出以下错误。从那时起,信息就不再被消费。同样,根据消费者群体工具,消费者补偿正在向前推进

[2018-01-01 19:18:32,935] ERROR [Consumer clientId=consumer-1, groupId=new-group] Offset commit failed on partition starcom.status-4 at offset 0: This is not the correct coordinator. (org.apache.kafka.clients.consumer.internals.ConsumerCoordinator)
[2018-01-01 19:18:32,936] WARN [Consumer clientId=consumer-1, groupId=new-group] Asynchronous auto-commit of offsets {starcom.status-4=OffsetAndMetadata{offset=0, metadata=''}, starcom.status-5=OffsetAndMetadata{offset=0, metadata=''}, starcom.status-6=OffsetAndMetadata{offset=2, metadata=''}} failed: Offset commit failed with a retriable exception. You should retry committing offsets. The underlying error was: This is not the correct coordinator. (org.apache.kafka.clients.consumer.internals.ConsumerCoordinator)

结果是docker新手犯了个错误


当我在kafka控制台使用者shell上按住ctrl+ced键时,容器(group.id:“console group”)被置于分离模式。直到运行
docker ps[-n |-a]
命令,我才知道这一点。当我使用相同的命令启动另一个控制台使用者时(
docker run--net=host confluentinc/cp kafka:4.0.0 kafka console consumer--bootstrap server localhost:19092,localhost:29092,localhost:39092--topic starcom.status--from start--group console group
),使用者加入了相同的“控制台组”。这就是为什么在后台运行的第一个使用者会使用后续消息(显然我是在使用相同的分区键生成消息),并给我留下消息丢失的错误印象。这就是为什么消费者团体司令部显示了正确的补偿进展。在不同的窗口中将原始使用者重新连接到前台(
docker attach
)后,现在我看到所有生成的消息都在两个不同的控制台中根据分区分配进行使用。一切如期进行。很抱歉出现了错误警报,但希望遇到相同问题的人能从中得到一些提示。

总之,如果我想使用一些消息,在docker环境中设置kafka控制台使用者的正确方法应该是

docker run --net=host --rm -i -t \ 
    confluentinc/cp-kafka:4.0.0 \
      kafka-console-consumer --bootstrap-server localhost:19092,localhost:29092,localhost:39092 --topic foo.bar

注意这里有--rm,-i,-t选项-如果传递了--max消息,则不需要使用i和-t,在这种情况下,控制台将正常退出,停止并拆除容器

控制台使用者只是JavaAPI的包装器,但它不能重新建立到新分区的连接?如果是这样,似乎是网络/配置问题。如果您只是杀死一个docker容器,那么它将丢失该BrokerTank的所有相关数据以供评论。然而,正如我上面所说的,如果我不通过--group选项,控制台消费者可以在不愉快的代理中断中生存下来——这是一件非常好的事情。这使我相信这不是一个网络/配置问题。上面提供了更多错误消息。您是如何生成消息的?您确定它们已分发给其他经纪人吗?这一主题真的需要两个小时才能重新平衡吗?谢谢你的后续提问。然而,我想我已经追根究底了。请看我的答案。您可能应该使用
docker run--rm
Yes--rm选项肯定会帮助清理停止的容器。然而,我认为罪魁祸首更多的是没有提供-I和-t选项。
docker run --net=host --rm -i -t \ 
    confluentinc/cp-kafka:4.0.0 \
      kafka-console-consumer --bootstrap-server localhost:19092,localhost:29092,localhost:39092 --topic foo.bar