kafka-11 Coordinator与offset管理和Consumer Rebalance

kafka的offset管理

• kafka在0.8（含）之前的版本都是用ZK来管理offset
  目录结构是：/consumers//offsets//，zk是做分布式系统的协调的，轻量级的元数据存储，不能负责高并发读写，尤其是写操作。
• kafka在0.8之后的版本是提交offset发送给内部topic：__consumer_offsets
• 提交过去的时候，key是group.id+topic+分区号，value就是当前offset的值
• 每隔一段时间，kafka内部会对这个topic进行compact。也就是每个group.id+topic+分区号就保留最新的那条数据即可。而且因为这个 __consumer_offsets可能会接收高并发的请求，所以默认分区50个，这样如果你的kafka部署了一个大的集群，比如有50台机器，就可以用50台机器来抗offset提交的请求压力，就好很多。
  

kafka之coordinator

coordinator的作用

个consumer group都会选择一个broker作为自己的coordinator，他是负责监控这个消费组里的各个消费者的心跳，以及判断是否宕机，然后开启rebalance.
根据内部的一个选择机制，会挑选一个对应的Broker，Kafka总会把你的各个消费组均匀分配给各个Broker作为coordinator来进行管理的.
consumer group中的每个consumer刚刚启动就会跟选举出来的这个consumer group对应的coordinator所在的broker进行通信，然后由coordinator分配分区给你的这个consumer来进行消费。coordinator会尽可能均匀的分配分区给各个consumer来消费

coordinator的选择

• 首先对消费组的groupId进行hash
• 接着对consumer_offsets的分区数量取模，默认是50（可以通过offsets.topic.num.partitions来设置）。找到consumer group的offset要提交到consumer_offsets的哪个分区。
  • 比如说：groupId，“membership-consumer-group” -> hash值（数字）-> 对50取模 -> 就知道这个consumer group下的所有的消费者提交offset的时候是往哪个分区去提交offset，找到consumer_offsets的一个分区，consumer_offset的分区的副本数量默认来说1，只有一个leader
• 然后对这个分区找到对应的leader所在的broker，这个broker就是这个consumer group的coordinator了，consumer接着就会维护一个Socket连接跟这个Broker进行通信。

简单来讲：就是先确定consumer group位移写入哪个consumer_offsets的哪个分区，该分区leader所在broker就是broker。

consumer消费策略的制定

1.选举出coordinator后

2.多个consumer都向coordinator发送注册请求。谁先发送成功就选举谁为leader consumer

3.leader consumer制定消费方案

4.leader consumer发送消费方案给coordinator

5…leader consumer发送消费方案给其他comsumer

6.consumers按照消费方案消费

consumer消费者Rebalance

什么是rebalance？

rebalance本质上是一种协议，规定了一个consumer group下的所有consumer如何达成一致来分配订阅topic的每个分区。比如某个group下有20个consumer，它订阅了一个具有100个分区的topic。正常情况下，Kafka平均会为每个consumer分配5个分区。这个分配的过程就叫rebalance。
Kafkaconsumer提供了三种分配策略

• range
• round-robin
• sticky

rebalance的触发条件有三种：

• 组成员发生变更(新consumer加入组、已有consumer主动离开组或已有consumer崩溃了）
• 订阅主题数发生变更——这当然是可能的，如果你使用了正则表达式的方式进行订阅，那么新建匹配正则表达式的topic就会触发rebalance
• 订阅主题的分区数发生变更

设我们消费的一个topic主题有12个分区：p0,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11
假设我们的消费者组里面有三个消费者，消费者成员减少一个
下面以此例进行分析对比

range范围策略（默认策略）

range策略就是按照partiton的序号范围
p0~3 consumer1
p4~7 consumer2
p8~11 consumer3
默认就是这个策略

假设consuemr1挂了:p0-5分配给consumer2,p6-11分配给consumer3
这样的话，原本在consumer2上的的p6,p7分区就被分配到了 consumer3上。做了不必要的数据迁移

round-robin轮训策略

consumer1: 0,3,6,9
consumer2: 1,4,7,10
consumer3: 2,5,8,11

假设consuemr1挂了:p0-5分配给consumer2,p6-11分配给consumer3
这样的话，原本在consumer2上的的p6,p7分区就被分配到了 consumer3上。做了不必要的数据迁移

sticky粘性策略

最新的一个sticky策略，就是说尽可能保证在rebalance的时候，让原本属于这个consumer
的分区还是属于他们，然后把多余的分区再均匀分配过去，这样尽可能维持原来的分区分配的策略

consumer1： 0-3
consumer2: 4-7
consumer3: 8-11

假设consumer3挂了
consumer1：0-3，+8,9
consumer2: 4-7，+10,11

消费者分配策略设置

默认是RangeAssignor表示范围策略

//设置消费者分配策略：
properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, 
StickyAssignor.class.getName());