kafka consumer group设计的巧妙以及讨厌的rebalance

一.consumer group的特性

• consumer group下可能有一个或多个consumer实例
• group ID是一个字符串，在一个kafka集群中，它标识唯一的consumer group
• 一个consumer group下面的实例只能消费一个主题的分区，当然这个分区也能被其它consumer group消费

二.特性导致的好处

由上面三个特性，我们能想到kafka consumer group这个机制却实现了传统消息系统的两大模型：**如果所有实例都属于同一个group，那么此时kafka就是消息队列模型；如果所有实例都分别属于不同的的group，那么此时kafka就是一个发布订阅模型。**理想情况下，consumer实例的数量应该等于group订阅主题的分区总数。

三.每个group如何管理它的offset

我们都知道offset是记录分区消费位置信息，对于consumer group而言，可以简单理解为一个Map的数据结构。那么问题来了，这个会频繁变动的offset值保存在哪里呢？
在老版本的时候，offset是保存在zookeeper，这样做最显而易见的做法是减少了broker的端保存的开销，但是zookeeper这个中间件其实是不适合做这种频繁的操作的，这种大量的操作会严重拖慢zookeeper的性能。后来社区重新设计了_consumer_offsets这样一个内部主题来管理offsets。
_consumer_offsets主要是保存kafka消费者的位移信息，它需要这个过程不仅要实现高可用性，更需要高频的写，那么其实kafka的主题设计天然满足这两个需求，位移主题的key应该包括三部分内容–，这样就很容易找到当前group消费某主题下的某个分区的offset值。

四.Rebalance

rebalance本质上是一种协议，规定了一个consumer group下的所有consumer如何达成一致，来分配订阅topic的每个分区。
kafka触发rebalance的条件有三个：

• 1.consumer group实例的变化。比如新的consumer加入组或者老的consumer离开组，以及consumer意外崩溃离开组
• 2.consumer group订阅的主题数目发生变更。比如通过正则表达式订阅主题，有新的主题加入的时候自动订阅这个主题数。
• 3.分区数的变化。
  rebalance发生的时候，consumer group下的consumer都会协调在一起共同参与，尽最大努力保持每个consumer实例获取到较为公平的分区数。但是rebalance的时候所有的consumer实例都会停止消费，导致rebalance完成，如果你的consumer group实例特别多的话，一次rebalance的时间会非常长，这个代价难以想象，而社区对于这个现象无能为力，最好的办法就是通过好的设计以及预防措施防止group进行rebalance。