KafkaConsumer 分析

image.png

1. Old Low Level Consumer API

1.1 优缺点

1.1.1优点

使用Low Level Consumer (Simple Consumer)的主要原因是，用户希望比Consumer Group更好的控制数据的消费。比如：
1.同一条消息读多次
2.只读取某个Topic的部分Partition
3.管理事务，从而确保每条消息被处理一次，且仅被处理一次
4.可以做到at-least-once或者exactly-once

1.1.2缺点

1.与Consumer Group相比，Low Level Consumer要求用户做大量的额外工作
必须在应用程序中跟踪offset，从而确定下一条应该消费哪条消息
2.应用程序需要通过程序获知每个Partition的Leader是谁,必须处理Leader的变化

1.1.3使用Low Level Consumer的一般流程如下

1.查找到一个“活着”的Broker，并且找出每个Partition的Leader
2.找出每个Partition的Follower
3.定义好请求，该请求应该能描述应用程序需要哪些数据
4.Fetch数据
5.识别Leader的变化，并对之作出必要的响应

1.2 源码解析

image.png

2. Old High Level Consumer API

2.1 优缺点

2.1.1优点

很多时候，客户程序只是希望从Kafka读取数据，不太关心消息offset的处理。同时也希望提供一些语义，例如同一条消息只被某一个Consumer消费（单播）或被所有Consumer消费（广播）。因此，Kafka Hight Level Consumer提供了一个从Kafka消费数据的高层抽象，从而屏蔽掉其中的细节并提供丰富的语义。
exactly-once

2.1.2缺点

目前，最新版（0.8.2.1）Kafka的Consumer Rebalance的控制策略是由每一个Consumer通过在Zookeeper上注册Watch完成的。每个Consumer被创建时会触发Consumer Group的Rebalance，具体启动流程如下：

High Level Consumer启动时将其ID注册到其Consumer Group下，在Zookeeper上的路径为/consumers/[consumer group]/ids/[consumer id]
在/consumers/[consumer group]/ids上注册Watch
在/brokers/ids上注册Watch
如果Consumer通过Topic Filter创建消息流，则它会同时在/brokers/topics上也创建Watch
强制自己在其Consumer Group内启动Rebalance流程

在这种策略下，每一个Consumer或者Broker的增加或者减少都会触发Consumer Rebalance。因为每个Consumer只负责调整自己所消费的Partition，为了保证整个Consumer Group的一致性，当一个Consumer触发了Rebalance时，该Consumer Group内的其它所有其它Consumer也应该同时触发Rebalance。

该方式有如下缺陷：

Herd effect
　　任何Broker或者Consumer的增减都会触发所有的Consumer的Rebalance
Split Brain
　　每个Consumer分别单独通过Zookeeper判断哪些Broker和Consumer 宕机了，那么不同Consumer在同一时刻从Zookeeper“看”到的View就可能不一样，这是由Zookeeper的特性决定的，这就会造成不正确的Reblance尝试。
调整结果不可控
　　所有的Consumer都并不知道其它Consumer的Rebalance是否成功，这可能会导致Kafka工作在一个不正确的状态。

2.2 源码解析

image.png

3. New Consumer API

1.java语言编写
2.comsumer offset保存于KafkaCluster的__consumer_offsets topic中，0.8.2版本的consumer offset保存于zk中，可以去zk上手动修改offset
3.支持自己commit offset与自动commit offset

4.kafka to sparkstreaming的两种模式解析

image.png

KafkaConsumer 分析