kafka connect rebalance时herder大概率异常

1. 发生场景

版本:confluent 2.0.0
如果因为some reason触发了task的rebalance,herder work可能发生异常,导致connect进程退出

2. 异常栈
[2016-06-28 17:22:59,934] ERROR Uncaught exception in herder work thread, exiting:  (org.apache.kafka.connect.runtime.distributed.DistributedHerder:166)
java.util.ConcurrentModificationException: KafkaConsumer is not safe for multi-threaded access
        at org.apache.kafka.clients.consumer.KafkaConsumer.acquire(KafkaConsumer.java:1294)
        at org.apache.kafka.clients.consumer.KafkaConsumer.close(KafkaConsumer.java:1225)
        at org.apache.kafka.connect.runtime.WorkerSinkTask.close(WorkerSinkTask.java:128)
        at org.apache.kafka.connect.runtime.Worker.stopTask(Worker.java:313)
        at org.apache.kafka.connect.runtime.distributed.DistributedHerder$14.onRevoked(DistributedHerder.java:898)
        at org.apache.kafka.connect.runtime.distributed.WorkerCoordinator.onJoinPrepare(WorkerCoordinator.java:236)
        at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureActiveGroup(AbstractCoordinator.java:207)
        at org.apache.kafka.connect.runtime.distributed.WorkerGroupMember.poll(WorkerGroupMember.java:142)
        at org.apache.kafka.connect.runtime.distributed.DistributedHerder.tick(DistributedHerder.java:266)
        at org.apache.kafka.connect.runtime.distributed.DistributedHerder.run(DistributedHerder.java:159)
        at java.lang.Thread.run(Thread.java:745)
[2016-06-28 17:22:59,936] INFO Kafka Connect stopping (org.apache.kafka.connect.runtime.Connect:68)
3. 异常分析
1. 线程模型

confluent存在两种worker:
(1)控制数据读写 的source/sink worker;
(2)负责协调source/sink worker的herder worker;
当rebalance发生时,herder会去主动close worker线程。

2. 关键方法

从栈中可以看出,在KafkaConsumer.acquire方法中抛出的异常,分析下该方法:
(1)本意:阻止多个线程对同一分区数据进行读写操作。
(2)实现手段:非阻塞锁的思路,用变量记录了当前的操作线程。一个线程来操作时,如果发现其他线程也在操作就退出。
这个控制手段很粗暴,它应该做的是“不许多个sink worker同时操作“。而不是一棒子全打死,不许所有线程操作。

3. 问题

herder 主动去杀sink worker,会操作Consumer。如果sink worker正在操作就会发生异常。

4. 解决办法
  1. herder close sink worker时,不要走acquire流程;
  2. herder close sink worker时,先等待一定时长(sleep或者加锁)
  3. 在V3.0.0 版本,框架上做了改动,herder 只是置位close标记,不错其他的操作。
### 回答1: Kafka的rebalance会影响消费者组内各个消费者的分区分配,从而影响消费者的消费速度和消费顺序。 当消费者加入或离开消费者组Kafka会触发rebalance操作,重新分配消费者组内各个消费者所消费的分区。这个过程可能会导致一些消费者需要重新连接分区,从而影响消费速度;同也可能会导致某些消息的消费顺序发生变化,因为消费者之间重新分配了分区。 因此,在使用Kafka,需要考虑好消费者组的设置和rebalance的触发条件,以及如何处理rebalance操作对消费者的影响。 ### 回答2: Kafka的rebalance(重新平衡)是指在Kafka集群中添加或删除broker或者消费者,自动重新分配分区给消费者的过程。它主要影响了Kafka集群的可用性、消费者的负载均衡和消费顺序。 首先,rebalance会影响Kafka集群的可用性。当添加或删除broker,集群需要重新分配分区以保持数据的冗余备份,这可能导致集群的可用性下降,在重新平衡期间,某些分区可能无法访问。 其次,rebalance会影响消费者的负载均衡。消费者组内的不同消费者订阅同一个主题的不同分区,rebalance会重新分配分区给消费者,以确保每个消费者负责处理大致相同数量的分区。这样可以确保消费者之间的负载均衡,避免某个消费者过载而导致延迟增加,同还能充分利用集群的吞吐量。 另外,rebalance还会影响消费顺序。Kafka保证同一个分区中的消息顺序,但在rebalance之后,分区被重新分配给其他消费者,这可能导致之前已经按顺序消费的消息重新分配给新的消费者,打乱消息的顺序。因此,消费者需要在rebalance之后重新定位到正确的位置,以确保顺序消费。 总之,Kafka的rebalance对可用性、负载均衡和消费顺序都有一定程度的影响。它在集群扩容、缩容或消费者组内的消费者变化自动进行,为Kafka提供了高可靠性和可伸缩性的支持。 ### 回答3: Kafka的rebalance指的是Kafka集群重新分配partition给不同的consumer,主要影响如下: 1. 分区的重新分配: 当某个consumer加入或离开Kafka集群,rebalance会导致已有partition的重新分配。这可能会导致消费者重复消费或漏掉某些消息。重新分配带来的分区变化会影响到消费者的消息处理。 2. 消费者群组的重新平衡: 当消费者群组内的消费者数量发生变化,rebalance会重新分配分区给各个消费者,以达到负载均衡。消费者的重新平衡操作可能会导致消费者停止消费一段间,从而影响整个消费群组的消息处理能力和延迟。 3. 消费者的会话过期: 在Kafka中,消费者与broker保持心跳连接来维持会话状态。如果一个消费者长间没有发送心跳,broker会将该消费者视为失效,从而触发rebalance。消费者的会话过期会导致分区的重新分配,从而影响消费者停止消费和重新分配分区。 4. 效率和性能问题: rebalance涉及到大量partition的重新分配和消费者的重新注册,会导致一定的性能损耗和网络传输开销。尤其在集群中有大量的分区和消费者,rebalance可能会导致大量的网络流量和延迟增加。 综上所述,Kafka的rebalance可以影响消费者群组中消息的分配和消费,引起消息重复或丢失的问题,并可能导致消费者停止消费一段间。因此,在设计Kafka应用程序,需要合理规划消费者群组和分区的数量,以减少rebalance对系统运行的影响。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值