kafka消费者重平衡可以避免吗？

什么是kafka消费者重平衡

  Rebalance是让一个Consumer Group下的所有Consumer实例就如何消费订阅主题的所有分区达成一个共识的过程。在Rebalance过程中，所有Consumer实例共同参与，在协调者的帮助下，完成订阅主题分区的分配。但是在此过程中，所有实例都不能消费任何消息，因此它对Consumer的TPS有很大影响。
  在这里，稍微说一下“协调者”（Coordinator）。后面会用到。
  具体来说，Consumer端应用程序在提交位移时，其实是向Coordinator所在的Borker提交位移的。同样，当Consumer应用启动时，也是向Coordinator所在的Borker发送各种请求，然后由Coordinator负责执行消费者组的注册，成员管理记录等元数据管理操作。

重平衡的弊端

1. Rebalance影响Consumer端TPS。
2. Rebalance很慢。如果你的Group下的成员很多就会很费时间。
3. Rebalance效率不高。当前是所有成员都参与，如果可以部分参与最好了。
     在真是业务中，很多Rebalance都是计划之外的或者说是不必要的。

重平衡发生的时机

rebalance发生的时机有三个：

1. 组成员数量发生变化时。
2. 订阅主题数量发生变化时。
3. 订阅主题的分区数发生变化时。
     通常后两个是运维的主动操作，所以他们的Rebalance不可避免。其实大多数的Rebalance是由于组成员发生变化造成的。

那些重平衡可以避免如何避免。

  组成员变化中：其中组成员增加很好理解，是我们自己启动一个配置有相同group.id值的Consumer程序时，就是添加了一个成员。这个不可避免。
  组成员减少这种情况，如果是你自己停掉的某个Consumer那没事。需要注意的是有些情况下Consumer实例会被Coordinator错误的认为“已停止”从而被踢出Group。
  什么情况下Coordinator会认为Consumer实例已经挂掉了？
  当Rebalance完成后，每个Consumer实例都会定期向Coordinator发送心跳请求，表明他还活着。如果消费者实例没有在规定时间内发送心跳请求，则Coordinator则会认为该消费者实例以及挂掉。从而，将其踢出，重新开启Rebalance。
  设置的参数：
session.timeout.ms：决定了，Consumer存活性的时间间隔。
heartbeat.interval.ms:控制发送心跳请求的频率。
max.poll.interval.ms:限定Consumer端应用程序两次调用poll方法的最大时间间隔。默认5分钟。如果五分钟之内没有消费完poll方法返回的消息，那Consumer会主动发起离开消费者组的请求。
总结一下：
不必要的Rebalance：
1：未能及时发送心跳而导致的Rebalance，
2：Consumer消费时间太长导致的。