大数据-Kafka（十一）

                                 大数据-Kafka（十一）

consumer消费原理

Offset管理

每个consumer内存里数据结构保存对每个topic的每个分区的消费offset，定期会提交offset，老版本是写入zk，但是那样高并发请求zk是不合理的架构设计，zk是做分布式系统的协调的，轻量级的元数据存储，不能负责高并发读写，作为数据存储。所以后来就是提交offset发送给内部topic：consumer_offsets，提交过去的时候，key是group.id+topic+分区号，value就是当前offset的值，每隔一段时间，kafka内部会对这个topic进行compact。也就是每个group.id+topic+分区号就保留最新的那条数据即可。而且因为这个 consumer_offsets可能会接收高并发的请求，所以默认分区50个，这样如果你的kafka部署了一个大的集群，比如有50台机器，就可以用50台机器来抗offset提交的请求压力，就好很多。

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消费者Rebalance策略

比如我们消费的一个topic主题有12个分区：p0,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11
假设我们的消费者组里面有三个消费者。

range范围策略

• RangeAssignor（默认策略）

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

round-robin轮训策略

• RoundRobinAssignor

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黏性策略

• StickyAssignor

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

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

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

消费者分配策略

• 由参数partition.assignment.strategy控制，默认是RangeAssignor表示范围策略。

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

consumer核心参数

• heartbeat.interval.ms

默认值：3000

consumer心跳时间，必须得保持心跳才能知道consumer是否故障了，然后如果故障之后，就会通过心跳下发rebalance的指令给其他的consumer通知他们进行rebalance的操作。

• session.timeout.ms

默认值：10000    

kafka多长时间感知不到一个consumer就认为他故障了，默认是10秒

• max.poll.interval.ms

默认值：300000

如果在两次poll操作之间，超过了这个时间，那么就会认为这个consume处理能力太弱了，会被踢出消费组，分区分配给别人去消费，一遍来说结合你自己的业务处理的性能来设置就可以了

• fetch.max.bytes

默认值：1048576

获取一条消息最大的字节数，一般建议设置大一些。

• max.poll.records

默认值：500条

一次poll返回消息的最大条数

• connections.max.idle.ms

默认值：540000

consumer跟broker的socket连接如果空闲超过了一定的时间，此时就会自动回收连接，但是下次消费就要重新建立socket连接，这个建议设置为-1，不要去回收

• auto.offset.reset

earliest

当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费          

latest

当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从当前位置开始消费

none

topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset，则抛出异常
        
注：我们生产里面一般设置的是latest

• enable.auto.commit

默认值：true

设置为自动提交offset

• auto.commit.interval.ms

默认值：60 * 1000

每隔多久更新一下偏移量

如果消费者这端要保证数据被处理且只被处理一次：
屏蔽掉了下面这2种情况：
    （1）数据的重复处理
    （2）数据的丢失
    
一般来说：需要手动提交偏移量，需要保证数据处理成功与保存偏移量的操作在同一事务中就可以了。

此博文仅供学习参考，如有错误欢迎指正。

上一篇《大数据-Kafka（十）》

下一篇《大数据-scala（一）》