触发group rebalance的可能场景

  • 新成员加入
  • 组成员主动离开
  • 组成员崩溃

组成员崩溃

  • kafka消费者配置的四个参数:
    • session.timeout.ms 会话超时时间
    • heartbeat.interval.ms 心跳时间间隔
    • max.poll.interval.ms 每次消费处理时间
    • max.poll.records 每次消费的消息数
  • session.timeout.ms 表示consumer向broker发送心跳的超时时间.session.timeout.ms=18000表示18秒内，broker没有收到consumer的心跳，broker认为consumer异常，启动rebalance。
  • hearbeat.interval.ms 表示consumer每次向broker发送心跳的时间间隔.v0.10.2之前的心跳和消费在同一个线程完成，0.10.2之后维持心跳的线程和消费线程已分开.一般来说session.timeout.ms的值是heartbeat的3倍
  • max.poll.interval.ms 表示consumer每2次poll消息的时间间隔。该参数可以理解为consumer每次消费消息的最大时长，如果超过这个时间broker端还未收到poll请求,broker会认为consumer异常，触发rebalance。
  • max.poll.records 表示每次拉取的消息条数，注意这个不代表consumer每次能消费的条数，仅仅代表从broker拉取的消息条数，拉取后是放在client本地缓存中，consumer消费线程每次从缓存中读取一定量的消息来消费.如果poll消息数越多，耗时越长，需要保证必须在max.poll.interval.ms这个时间之前消费完，否则会触发rebalance。

总结

  • 消费者心跳超时，导致rebalance，相关参数:

    • session.timeout.ms
    • heartbeat.interval.ms

  • 消费者处理消息时间过长，导致rebalance，相关参数:

    • max.poll.interval.ms
    • max.poll.records

  • 一句话总结，处理好心跳超时问题和消费处理超时问题

解决方案

  • session.timeout.ms：配置控制心跳的超时时间，可以由客户端自行设置。
  • max.poll.records：控制每次poll返回的最大消息数量。
  • v0.10.2之前版本的客户端：心跳是通过poll接口来实现的，没有内置的独立线程。
  • v0.10.2及之后版本的客户端：为了防止客户端长时间不进行消费，Kafka客户端在v0.10.2及之后的版本中引入了max.poll.interval.ms配置参数。 为了避免心跳超时，引发Rebalance，请参考以下步骤进行调整：
  1. 参考以下说明调整参数值：
    • session.timeout.ms：v0.10.2之前的版本可适当提高该参数值，需要大于消费一批数据的时间，但不要超过30s，建议设置为25s；而v0.10.2及其之后的版本，保持默认值10s即可。
    • max.poll.records：降低该参数值，建议远远小于<单个线程每秒消费的条数> * <消费线程的个数> * <max.poll.interval.ms>的积。
    • max.poll.interval.ms: 该值要大于<max.poll.records> / (<单个线程每秒消费的条数> * <消费线程的个数>)的值。
  2. 尽量提高客户端的消费速度，消费逻辑另起线程进行处理。
  3. 减少Group订阅Topic的数量，一个Group订阅的Topic最好不要超过5个，建议一个Group只订阅一个Topic。
  4. 将客户端升级至0.10.2以上版本