kafka consumer相关文档阅读
This commit is contained in:
@@ -375,6 +375,22 @@ kafka中的分区策略通过`partition.assignment.strategy`参数来进行配
|
|||||||
> - `auto.commit.interval.ms`:自动提交默认的间隔时间为5s
|
> - `auto.commit.interval.ms`:自动提交默认的间隔时间为5s
|
||||||
>
|
>
|
||||||
> 在开启自动提交时,每次消费者调用poll接口时,都会检查是否距离上次提交的时间间隔已超过5s,若超过则执行自动提交逻辑。
|
> 在开启自动提交时,每次消费者调用poll接口时,都会检查是否距离上次提交的时间间隔已超过5s,若超过则执行自动提交逻辑。
|
||||||
|
>
|
||||||
|
> 在自动提交场景下,可能会造成消息的重复消费,如果自动提交的间隔为10s,在上次提交完成后,过了6s,消费完100条消息,但是此时消费者宕机了,导致消费的100条消息没有提交offset;此时该宕机消费者负责的分区将会被分配给消费者组中的其他消费者,其他消费者消费时仍然会从最后一次提交的offset开始消费,导致100条消息会被重复消费。
|
||||||
|
|
||||||
|
> #### kafka手动提交
|
||||||
|
> kafka可以选择设置手动提交,只用把`enable.auto.commit`关闭。kafka手动提交分为如下两种场景:
|
||||||
|
> - commitSync:同步提交。当关闭自动提交时,可以调用`commitSync`接口来进行手动提交。手动提交的offset为最后一次调用poll方法返回的offset。该方法通常在消费完所有poll返回的消息后再调用,否则若commit后消息还没有消费完,消费者宕机,则会导致消息丢失,有些消费不会被消费。<br>
|
||||||
|
> 在同步提交的场景下,调用commitSync后,线程会一直阻塞,直到接收到kafka server返回的ack,ack代表broker对commit offsets的确认
|
||||||
|
> - commitAsync:由于同步提交会造成阻塞,一直等待broker返回ack,故而会影响消息消费的吞吐量。可以通过异步提交来解决吞吐量问题,但是,`异步提交可能会造成更多消息被重复消费`。
|
||||||
|
|
||||||
|
> #### kafka手动提交、自动提交的优劣
|
||||||
|
> - kafka自动提交可能会造成消息的丢失,自动提交默认间隔为5s,如果在上次poll后的5s内消息并未被消费完成,那么在kafka自动提交后,即使尚未被消费的消息后续未被消费,那么kafka也会将其视为已消费,从而造成消息丢失
|
||||||
|
>
|
||||||
|
> - kafka commitSync可手动同步提交offset,但是在调用commitSync接口后,会等待broker返回确认信息,在此之前消费者会一直阻塞。这样会影响消费者的吞吐量,故而,为了提高吞吐量,可以尽量减少commitSync的提交次数
|
||||||
|
>
|
||||||
|
> - kafka commitAsync,相比于同步提交,commitAsync在调用后并不会阻塞,而是直接返回,此后可以继续调用poll来继续从broker拉取后续消息。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user