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的协作