Consumer

kafka

1、Kafka 的消费模式

消息队列中消息的消费模型通常有两种：推送模型（push）和拉取模型（pull）。

1.1 推送模型（push）

• 基于推送模型的消息队列，由消息代理记录消费者的消费状态，但这种方式往往无法很好地保证消息被处理。同时这种模式还有一个明显缺点，就是消息被标记为消费后，其它消费者则不可以再消费。

1.2 拉取模型（pull）

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

1.3 优缺点

• 在一些消息系统中，消息代理会在消息被消费之后立即删除消息。如果有不同类型的消费者订阅同一个主题，消息代理可能需要冗余地存储同一消息；或者等所有消费者都消费完才删除，这就需要消息代理跟踪每个消费者的消费状态，这种设计很大程度上限制了消息系统的整体吞吐量和处理延迟。Kafka 的做法是生产者发布的所有消息会一致保存在 Kafka 集群中，不管消息有没有被消费。用户可以通过设置保留时间来清理过期的数据，比如，设置保留策略为两天。那么，在消息发布之后，它可以被不同的消费者消费，在两天之后，过期的消息就会自动清理掉。

2、Consumer 的两套 API

kafka 给我们提供了两套 Consumer API，分别是 The high-level Consumer API 和 The SimpleConsumer API。（其中 High-level Consumer API 提供了一个从 Kafka 消费数据的高层抽象，而 SimpleConsumer API 则需要开发人员更多地关注细节。）

2.1 The high-level Consumer API

High-level Consumer API 提供了 Consumer Group 的语义，一个消息只能被 Group 内的一个 Consumer 所消费，且 Consumer 消费消息时不关注 offset，最后一个 offset 由 Zookeeper 保存。

同时 High-level consumer API 还支持多线程消费，但需要注意：

1）如果消费线程大于 Partition 数量，则有些线程将收不到消息。

2）如果 Partition 数量大于线程数，则有些线程多收到多个 Partition 的消息。

3）如果一个线程消费多个Partition，则无法保证接收消息的顺序，只能保证 Partition 内部有序。

2.2 The SimpleConsumer API

使用 The SimpleConsumer API，你可以对 Partition 有更多的控制权，如多次消费一个消息，只消费 Partition 中部分消息等。

但是使用此 API 时，Partition、Offset、Broker、Leader 等不再透明，需要业务去处理：

1）必须在应用程序中跟踪 Offset，从而确定下一条应该消费哪条消息。

2）应用程序需要通过程序获知每个 Partition 的 Leader，同时还需要处理 Leader 的变更。

3、Consumer Delivery Guarantee（消息投递保证）

如果将 Consumer 设置为 autocommit，Consumer 一旦读到数据立即自动 commit，但此处只考虑到了读取消息的过程，那 Kafka 确保了 Exactly once。但实际使用中 Consumer 还要对读取到的消息做进一步处理：

• 收到消息先提交再处理
  
  • 这种模式下，如果 consumer 在 commit 后还没来得及处理消息就 crash 了，下次重新开始工作后就无法读到刚刚已提交而未处理的消息，这就对应于 At most once
• 收到消息先处理再提交
  
  • 这种模式下，如果在处理完消息之后 commit 之前 consumer crash 了，下次重新开始工作时还会处理刚刚未 commit 的消息，实际上该消息已经被处理过了。这就对应于 At least once。
• 实现 Exactly once
  
  • 精典的做法是引入两阶段提交。除此以外如果能让 offset 和操作输入存在同一个地方，会更简洁和通用，且这种方式可能更好，因为许多输出系统可能不支持两阶段提交。