Kafka学习笔记（5）----Kafka的Consumer

1. Pull vs Push

　　Producer主动的经过push将消息发布到Broker上，Consumer经过Pull的的方式从Broker消息消息。

　　经过Push的方式因为是一有消息就推到Broker,因此极大的保证了消息实时性，可是在某些状况下，可能因为Consumer网络，或是其余缘由却是消费速度低，此时就可能会致使Consumer堆积大量的消息，甚至在极端状况下会压垮Consumer.

　　经过Pull拉取消息保证了Consumer可以按本身实际处理能力来拉取相应的消息，而且Broker的实现也相对简单，可是也会出如今消息处理能力很低的状况下形成消息的实时性太低。

　　kafka提供了High Level Consumer和High Level Consume两种方式的API。

2. High Level Consumer

　　不少应用场景下，客户程序只是但愿从Kafka顺序读取并处理数据，而不太关心具体的offset。它同时也但愿提供一些语义，例如同一条消息只被某一个Consumer消费（单播）或被全部Consumer消费（广播），Kafka High Level API提供了一个从Kafka消费数据的高层抽象，从而屏蔽掉其中的细节，并提供丰富的语义。

　　在Kafka中，High Level Consumer将从某个Partition读取的最后一条消息的offset存于Zookeeper中（从0.8.2开始同时支持将offset存于Zookeeper中和专用的Kafka Topic中）。这个offset基于客户程序提供给Kafka的名字来保存，这个名字被称为Consumer Group，Consumer Group是整个Kafka集群全局惟一的，而非针对某个Topic的。每一个High Level Consumer实例都属于一Consumer Group，若不指定则属于默认的Group。在消息被消费以后，消息并不会当即被删除，只是相应的offset加一，若以可能Consumer中的offset将会跟消息的数据同样多，

　　在High Level Consumer下因为存在了关联关系（Group ），因此消息删除也将再也不是到必定时间或消息条数达到某个值就删除，而是经过压缩的方式，保留最新的key的value的方式。具体示例以下：

　　

　　　这样就保证了消息与offset之间仍然是正确的对应关系。

　　对于每条消息，在同一个Consumer Gourp里都只会被一个Consumer消费，不一样的Cosumer Group能够消费同一条消息。

　　以下：

　　Kafka的设计理念之一就是同时提供对离线批处理和在线流处理的支持。能够同时使用Hadoop系统进行离线批处理，Storm或它流处理系统进行流处理。也可以使用Kafka的Mirror Maker将消息从一个数据中心镜像到另外一个数据中心。

　　如图：

　　

　　Consumer的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流程

　　Rebalance算法

　　1. 将目标Topic下的全部Partirtion排序，存于PT

　　2. 对某Consumer Group下全部Consumer排序，存于CG，第i个Consumer记为Ci

　　3. N=size(PT)/size(CG) ，向上取整

　　4. 解除Ci对原来分配的Partition的消费权（i从0开始）

　　5. 将第i∗N 到（i+1）∗N−1个Partition分配给Ci

　   Rebalance算法也存在以下缺点:

　　1. Herd Effect: 任何Broker或者Consumer的增减都会触发全部的Consumer的Rebalance

　　2. Split Brain: 每一个Consumer分别单独经过Zookeeper判断哪些Broker和Consumer宕机，同时Consumer在同一时刻从Zookeeper“看”到的View可能不彻底同样，这是由Zookeeper的特性决定的。

　　3. 调整结果不可控全部Consumer分别进行Rebalance，彼此不知道对应的Rebalance是否成功

3. Low Level Consumer　

　　使用Low Level Consumer (Simple Consumer)的主要缘由是，用户但愿比Consumer Group更好的控制数据的消费，如:

　　1. 同一条消息读屡次，方便Replay

　　2. 只消费某个Topic的部分Partition

　　3. 管理事务，从而确保每条消息被处理一次（Exactly once）

　　与High Level Consumer相对，Low Level Consumer要求用户作大量的额外工做

　　1. 在应用程序中跟踪处理offset，并决定下一条消费哪条消息

　　2. 获知每一个Partition的Leader

　　3. 处理Leader的变化

　　5. 处理多Consumer的协做