1.消费模型

消息的消费模型有两种：推送模型(push)和拉取模型(pull)

推送模型(push)：

基于推送模型（push）的消息系统，由消息代理记录消费者的消费状态，消息代理在将消息推送到消费者后，标记这条消息为已消费，但这种方式无法很好地保证消息被处理，比如，消息代理把消息发送出去后，当消费进程挂掉或者由于网络原因没有收到这条消息时，就有可能造成消息丢失（因为消息代理已经把这条消息标记为已消费了，但实际上这条消息并没有被实际处理），如果要保证消息被处理，消息代理发送完消息后，要设置状态为“已发送”，只有收到消费者的确认请求后才更新为“已消费”，这就需要消息代理中记录所有的消费状态，这种做法显然是不可取的

拉取模型(pull)：

Kafka采用拉取模型，由消费者自己记录消费状态，每个消费者互相独立地顺序读取每个分区的消息，有两个消费者(不同消费者组)拉取同一个主题的消息，消费者A的消费进度是3，消费者B的消费进度是6，消费者拉取的最大上限通过最高水位(watermark)控制，生产者最新写入的消息如果还没有达到备份数量，对消费者是不可见的，这种由消费者控制偏移量的优点是：消费者可以按照任意的顺序消费消息，比如：消费者可以重置到旧的偏移量，重新处理之前已经消费过的消息；或者直接跳到最近的位置，从当前的时刻开始消费

2.高级API

1)高级API优点:

高级API 写起来简单

不需要自行去管理offset，系统通过zookeeper自行管理。

不需要管理分区，副本等情况，.系统自动管理。

消费者断线会自动根据上一次记录在zookeeper中的offset去接着获取数据（默认设置1分钟更新一下zookeeper中存的offset）

可以使用group来区分对同一个topic 的不同程序访问分离开来（不同的group记录不同的offset，这样不同程序读取同一个topic才不会因为offset互相影响）

2)高级API缺点

不能自行控制offset（对于某些特殊需求来说）

不能细化控制如分区、副本、zk等

3.低级API

1)低级 API 优点4.

能够让开发者自己控制offset，想从哪里读取就从哪里读取

自行控制连接分区，对分区自定义进行负载均衡

对zookeeper的依赖性降低(如：offset不一定非要靠zk存储，自行存储offset即可，比如存在文件或者内存中)

2)低级API缺点

太过复杂，需要自行控制offset，连接哪个分区，找到分区leader 等

4.消费者组

消费者是以consumer group消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个topic，每个分区在同一时间只能由group中的一个消费者读取，但是多个group可以同时消费这个partition

5.消费方式

consumer采用pull(拉)模式从broker中读取数据：

push(推)模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的，它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息

对于Kafka而言，pull模式更合适，它可简化broker的设计，consumer可自主控制消费消息的速率，同时consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直等待数据到达。为了避免这种情况，我们在我们的拉请求中有参数，允许消费者请求在等待数据到达的“长轮询”中进行阻塞(并且可选地等待到给定的字节数，以确保大的传输大小)