卡夫卡消费者左消费群

时间:2019-02-18 14:51:49

标签: apache-kafka spring-kafka

使用Kafka时遇到了一些问题。任何帮助深表感谢! 我在docker swarm中每个都有zookeeper和kafka集群3个节点。您可以在下面看到Kafka经纪人配置。

  KAFKA_DEFAULT_REPLICATION_FACTOR: 3
  KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 3
  KAFKA_MIN_INSYNC_REPLICAS: 2
  KAFKA_NUM_PARTITIONS: 8
  KAFKA_REPLICA_SOCKET_TIMEOUT_MS: 30000
  KAFKA_REQUEST_TIMEOUT_MS: 30000
  KAFKA_COMPRESSION_TYPE: "gzip"
  KAFKA_JVM_PERFORMANCE_OPTS: "-XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80"
  KAFKA_HEAP_OPTS: "-Xmx768m -Xms768m -XX:MetaspaceSize=96m"

我的情况:

  • 20个制作人不断向kafka主题发送消息
  • 1x消费者读取和记录消息
  • 杀死kafka节点(docker容器停止),因此群集现在具有2个Kafka代理节点(第3个节点将自动启动并加入群集)
  • 并且消费者不再使用消息,因为它由于重新平衡而离开了消费者组

是否存在任何机制来告诉消费者重新平衡后加入群组?

日志:

 INFO 1 --- [ | loggingGroup] o.a.k.c.c.internals.AbstractCoordinator : [Consumer clientId=kafka-consumer-0, groupId=loggingGroup] Attempt to heartbeat failed since group is rebalancing
 WARN 1 --- [ | loggingGroup] o.a.k.c.c.internals.AbstractCoordinator : [Consumer clientId=kafka-consumer-0, groupId=loggingGroup] This member will leave the group because consumer poll timeout has expired. This means the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time processing messages. You can address this either by increasing max.poll.interval.ms or by reducing the maximum size of batches returned in poll() with max.poll.records.

1 个答案:

答案 0 :(得分:0)

@Rostyslav 每当我们通过消费者调用读取消息时,它会执行 2 个主要调用。

  1. 投票
  2. 提交

Poll 基本上是从 kafka 主题中获取记录,提交告诉 kafka 将其保存为已读消息,以免再次读取。虽然轮询少数参数起着主要作用:

  1. max_poll_records
  2. max_poll_interval_ms

仅供参考:变量名称是每个 python api。

因此,每当我们尝试从 Consumer 读取消息时,它都会在每个 max_poll_interval_ms 进行一次轮询调用,并且只有在处理了获取的记录(如 max_poll_records 中定义)之后才会进行相同的调用。因此,每当 max_poll_inetrval_ms 中未处理 max_poll_records 时,我们就会得到错误。

为了克服这个问题,我们需要改变两个变量之一。更改 max_poll_interval_ms c 可能会很忙,因为有时处理某些记录可能需要更长的时间,有时处理更少的记录。我总是建议使用 max_poll_records 来解决这个问题。这对我有用。