Kafka Consumer API 的使用

导读

Kafka具有两套消费者API：高级API、低级API。本文章将介绍两种API的区别以及使用时需要注意的地方。

低级API

1. 使用方法

1. find leader broker
2. build request
3. fetch data
4. identify leader change

2. 为什么要find leader

kafka在0.8版本后，引入replication机制。每个partition是有备份的，在某个broker出故障后，用户仍可以从其他备份中读取数据。消费者并不是并行从多个broker上获取同一个partition的数据，而是选举出一个leader broker,这个broker上的该partition将用于读写。其他的partition则复制leader broker上partition的数据，保持同步。

备份个数由创建topic时，replica-factory决定，当该参数为1时，表示不备份，大于1时，每个partition将有多个备份partition，且分布在不同的broker上。

3. 适合场合

1. 消费起点需要设置
2. 反复消费某一段数据

备注：笔者项目中有一个需求是，解析数据时，既可以支持从断点消费，又可以支持从当前位移消费。这个需求就使用了这个API实现功能。

高级API

1. 原理

高级API使用，围绕数据流工作，利用的低级API消费数据。用户不用关心leader broker、offset等问题。

2. 线程

使用高级API时，需要关注线程问题。

用户在使用高级API时，需要指定每个topic获取数据的线程数量。一个线程对应一个数据流。但是寻找主分区、创建流、设置offset这些过程中，高级API仍只有一个线程。只有当从partition中获取数据时，每个流才会产生一个fetchRunable的线程。

每个topic的线程数，最好设置为等于或者小于topic的partition个数。

3. Zookeeper

Kafka的使用需要Zookeeper有以下原因:

1. 动态集群扩展。
2. broker的注册,保存topic、partition元数据。
3. consumer的注册。
4. watcher的注册。

而高级API使用中，上述Zookeeper的作用全都用到了。首先，均衡（balance）partition和consumer时，需要两者信息。第二，kafka通过Watcher知道broker、topic、partition是否有变化。第三，kafka通过与zk通讯监控partition leader存活性.

另外，在笔者实验中发现，用kill指令杀死进程时，该进程中kafka消费者在zk中的注册信息可能并没有及时删除，如果马上拉起这个进程，将会可能出现消费者大于partition个数的情况。这种情况并不是必现，原因可能和kafka与zk的通讯时间有关系（会多查阅一点资料，验证猜想是否正确）

4. Rebalance

因为每个流，其实都需要指定数据来源的partition.每次创建线程，从partion中获取数据时，需要将同一个topic所有的partition和该group中消费该topic的所有线程合理分配，保证每一个partition只被一个线程消费。这个过程叫做balance,由高级API自动完成。

当发生以下三种情况的时候，会触发Kafka高级API的rebalance动作：

1. 同一个group下，有新的消费者加入。
2. 同一个group下，有topic的partition个数有变化。
3. kafka API与zk的连接中断。

前两种情况比较好理解，重点讲第三种情况。我的理解是，zk超时或者断开后，kafka没有注册partition的信息，需要重新连接zk获取最新的注册信息，并根据新获取的信息进行线程、分区之间的分配和均衡。（个人理解，我会多查阅一些资料证实。）

zk超时后rebalance其实是很有可能不成功，并导致更多次的rebalance。原因是，如果kafka rebalance尝试的总时间（即尝试次数*每次尝试时间）小于zk超时时间，那么在zk连接失败重连之前，kafka的rebalance已经失败。这个原因可能会导致高级API不断的rebalance。而高级API默认设置参数，rebalance的尝试总时间是小于zk超时时间的，所以大家使用高级API时要根据实际情况处理这一点。

作者：君子月满楼 链接：https://www.jianshu.com/p/4d03ee74ad66 來源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。