Kafka重平衡导致无限循环消费问题

1. 问题描述

Kafka消费者消费消息超过了5分钟，不停的触发重平衡，消费者的offset因为重平衡提交失败，重复拉取消费，重复消费。

2. 问题原因

kafka默认的消息消费超时时间max.poll.interval.ms = 300000, 也就是5分钟，超过5分钟，会认为当前消费者已经死掉，会主动发起重平衡。

3. 解决方案

1. 减小kafka一批次拉取的数据量: max.poll.records，加快消费者消费的速度，控制拉取的消息能在短时间内消费掉
2. 拉取到消息之后异步处理（保证成功消费）
3. 调大 拉取消息线程最长空闲时间：max.poll.interval.ms

重复消费有哪些原因

消息重复消费的根本原因都在于：已经消费了数据，但是offset没有成功提交。

offset提交失败，很大一部分原因在于发生了重平衡：

1. 消费者宕机、重启等。导致消息已经消费但是没有提交offset。
2. 消费者使用自动提交offset，但当还没有提交的时候，有新的消费者加入或者移除，发生了rebalance。再次消费的时候，消费者会根据提交的偏移量来，于是重复消费了数据。
3. 消息处理耗时，或者消费者拉取的消息量太多，处理耗时，超过了max.poll.interval.ms的配置时间，导致认为当前消费者已经死掉，触发重平衡。

Kafka知识回顾

1. 常见配置参数

### broker
# offset 保留时间，默认为7天
offsets.retention.minutes=10080


### producer
# 生产者会尝试将业务发送到相同的 Partition 的消息合包发送到 Broker，batch.size 设置合包的大小上限。默认为 16KB。batch.size 设太小会导致吞吐下降，设太大会导致内存使用过多。
batch.size=16384

# Kafka producer 的 ack 有 3 种机制，分别说明如下：
# -1 或 all：Broker 在 leader 收到数据并同步给所有 ISR 中的 follower 后，才应答给 Producer 继续发送下一条（批）消息。 这种配置提供了最高的数据可靠性，只要有一个已同步的副本存活就不会有消息丢失。注意：这种配置不能确保所有的副本读写入该数据才返回，可以配合 Topic 级别参数 min.insync.replicas 使用。
# 0：生产者不等待来自 broker 同步完成的确认，继续发送下一条（批）消息。这种配置生产性能最高，但数据可靠性最低（当服务器故障时可能会有数据丢失，如果 leader 已死但是 producer 不知情，则 broker 收不到消息）
# 1：生产者在 leader 已成功收到的数据并得到确认后再发送下一条（批）消息。这种配置是在生产吞吐和数据可靠性之间的权衡（如果leader已死但是尚未复制，则消息可能丢失）
# 用户不显示配置时，默认值为1。用户根据自己的业务情况进行设置
acks=1

# 控制生产请求在 Broker 等待副本同步满足 acks 设置的条件所等待的最大时间
timeout.ms=30000

# 配置生产者用来缓存消息等待发送到 Broker 的内存。用户要根据生产者所在进程的内存总大小调节
buffer.memory=33554432

# 当生产消息的速度比 Sender 线程发送到 Broker 速度快，导致 buffer.memory 配置的内存用完时会阻塞生产者 send 操作，该参数设置最大的阻塞时间
max.block.ms=60000

# 设置消息延迟发送的时间(ms)，这样可以等待更多的消息组成 batch 发送。默认为0表示立即发送。当待发送的消息达到 batch.size 设置的大小时，不管是否达到 linger.ms 设置的时间，请求也会立即发送
# 推荐用户根据实际使用场景，设置linger.ms在100~1000之间，更大的取值相对有更大的吞吐但会相应增加时延
linger.ms=100

# 设置分区缓存消息量(bytes)，达到该数值时生产者将批量的消息发送给broker。默认值为16384，过小的batch.size会增加发送请求次数可能会损耗性能和影响稳定性，用户根据实际场景，可适当增大该值。注：该值为上限值，当还未达到时若时间已经达到linger.ms时生产者会发送消息
batch.size=16384

# 生产者能够发送的请求包大小上限，默认为1MB。在修改该值时注意不能超过 Broker 配置的包大小上限16MB
max.request.size=1048576

# 压缩格式配置，目前 0.9(包含)以下版本不允许使用压缩，0.10（包含）以上不允许使用 GZip 压缩
compression.type=[none, snappy, lz4]

# 客户端发送给 Broker 的请求的超时时间，不能小于 Broker 配置的 replica.lag.time.max.ms，目前该值为10000ms
request.timeout.ms=30000

# 客户端在每个连接上最多可发送的最大的未确认请求数，该参数大于1且 retries 大于0时可能导致数据乱序。 希望消息严格有序时，建议客户将该值设置1
max.in.flight.requests.per.connection=5

# 请求发生错误时重试次数，建议将该值设置为大于0，失败重试最大程度保证消息不丢失
retries=0

# 发送请求失败时到下一次重试请求之间的时间
retry.backoff.ms=100


### Consumer
# 是否在消费消息后将 offset 同步到 Broker，当 Consumer 失败后就能从 Broker 获取最新的 offset, 如果使用 spring-kafka，即使设置false，也会自动提交，因为false表示的是kafka客户端放弃自动提交，把权利交给Spring框架，消息消费后Spring框架还是会帮你自动提交
enable.auto.commit=true

# 当 auto.commit.enable=true 时，自动提交 Offset 的时间间隔，建议设置至少1000
auto.commit.interval.ms=5000

# 当 Broker 端没有 offset（如第一次消费或 offset 超过7天过期）时如何初始化 offset，当收到 OFFSET_OUT_OF_RANGE 错误时，如何重置 Offset
# earliest：表示自动重置到 partition 的最小 offset
# latest：默认为 latest，表示自动重置到 partition 的最大 offset
# none：不自动进行 offset 重置，抛出 OffsetOutOfRangeException 异常
auto.offset.reset=latest

# 标识消费者所属的消费分组
group.id=""

# 使用 Kafka 消费分组机制时，消费者超时时间。当 Broker 在该时间内没有收到消费者的心跳时，认为该消费者故障失败，Broker 发起重新 Rebalance 过程。目前该值的配置必须在 Broker 配置group.min.session.timeout.ms=6000和group.max.session.timeout.ms=300000 之间
session.timeout.ms=10000

# 使用 Kafka 消费分组机制时，消费者发送心跳的间隔。这个值必须小于 session.timeout.ms，一般小于它的三分之一
heartbeat.interval.ms=3000

# 使用 Kafka 消费分组机制时，再次调用 poll 允许的最大间隔。如果在该时间内没有再次调用 poll，则认为该消费者已经失败，Broker 会重新发起 Rebalance 把分配给它的 partition 分配给其他消费者
max.poll.interval.ms=300000

# Fecth 请求最少返回的数据大小。默认设置为 1B，表示请求能够尽快返回。增大该值会增加吞吐，同时也会增加延迟
fetch.min.bytes=1

# Fetch 请求最多返回的数据大小，默认设置为 50MB
fetch.max.bytes=52428800

# Fetch 请求等待时间
fetch.max.wait.ms=500

# Fetch 请求每个 partition 返回的最大数据大小，默认为1MB
max.partition.fetch.bytes=1048576

# 在一次 poll 调用中返回的记录数
max.poll.records=500

# 客户端请求超时时间，如果超过这个时间没有收到应答，则请求超时失败
request.timeout.ms=305000

2. poll机制

1. 每次poll的消息处理完成之后再进行下一次poll，是同步操作
2. 每次poll之前检查是否可以进行位移提交，如果可以，那么就会提交上一次轮询的位移
3. 每次poll时，consumer都将尝试使用上次消费的offset作为起始offset，然后依次拉取消息
4. poll(long timeout)，timeout指等待轮询缓冲区的数据所花费的时间，单位是毫秒

3. 重平衡 rebalance

将分区的所有权从一个消费者转移到其他消费者的行为称为再均衡（重平衡，rebalance）。

消费者通过向组织协调者（kafka broker）发送心跳来维护自己是消费者组的一员并确认其拥有的分区。对于不同不的消费群体来说，其组织协调者可以是不同的。只要消费者定期发送心跳，就会认为 消费者是存活的并处理其分区中的消息。当消费者检索记录或者提交它所消费的记录时就会发送心跳。

如果过了一段时间Kafka停止发送心跳了，会话（session）就会过期，组织协调者就会认为这个consumer已经死亡，就会触发一次重平衡。如果消费者宕机并且停止发送消息，组织协调者会等待几秒钟，确认它死亡了才会触发重平衡。在这段时间里，死亡的消费者将不处理任何消息。在清理消费者时，消费者将通知协调者它要离开群组，组织协调者会触发一次重平衡，尽量降低处理停顿。

重平衡是一把双刃剑，它为消费者群组带来高可用性和伸缩性的同时，还有有一些明显的缺点(bug)，而这些 bug 到现在社区还无法修改。也就是说，在重平衡期间，消费者组中的消费者实例都会停止消费（Stop The World），等待重平衡的完成。而且重平衡这个过程很慢。

触发重平衡的三种情况：
1. 消费者组内成员发生变更，这个变更包括了增加和减少消费者。注意这里的减少有很大的可能是被动的，就是某个消费者崩溃退出了
2. 主题的分区数发生变更，分区增加或者减少时就会触发重平衡
3. 订阅的主题发生变化，当消费者组使用正则表达式订阅主题，而恰好又新建了对应的主题，就会触发重平衡

重平衡异常：
max.poll.interval.ms，两次拉取消息的间隔，默认5分钟；通过消费组管理消费者时，该配置指定拉取消息线程最长空闲时间，若超过这个时间间隔没有发起poll操作，则消费组认为该消费者已离开了消费组，将进行重平衡操作（将分区分配给组内其他消费者成员）若超过这个时间则报如下异常：

>org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that 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 message processing. You can address this either by increasing the session timeout or by reducing the maximum size of batches returned in poll() with max.poll.records

4. 重复消费的解决方案

由于网络问题，重复消费不可避免，因此，消费者需要实现消费幂等。

方案：

1. 消息表
2. 数据库唯一索引
3. 缓存消费过的消息id

5. 消费者消费异常，会重试消费吗

1. enable.auto.commit=true：kafka消费者拉取到消息后，即使消费异常也会自动提交offset，不会重新消费 .
2. enable.auto.commit=false：
   2.1 手动提交offset，提交offset之前抛异常，则不会提交offset，因此会再次重新消费
   2.2 spring-kafka帮忙提交offset，不手动提交，spring框架会在最后提交offset，因此消费过程中抛异常，也不会提交offset，因此会再次重新消费