目录
消费者消费方式
consumer 采用 pull(拉)模式从 broker 中读取数据。
push(推)模式很难适应消费速率不同的消费者,因为消息发送速率是由 broker 决定的。 它的目标是尽可能以最快速度传递消息,但是这样很容易造成 consumer 来不及处理消息,典型的表现就是拒绝服务以及网络拥塞。而 pull(拉) 模式则可以根据 consumer 的消费能力以适当的速率消费消息。 pull (拉) 模式不足之处是,如果 kafka 没有数据,消费者可能会陷入循环中,一直返回空数据。针对这一点,Kafka 的消费者在消费数据时会传入一个时长参数 timeout,如果当前没有数据可供消费,consumer 会等待一段时间之后再返回,这段时长即为 timeout。
消费者的分区分配策略(也就是消费者如何从分区中消费数据)
一个 consumer group 中有多个 consumer,一个 topic 有多个 partition,所以必然会涉及到 partition 的分配问题,即确定哪个 partition 由哪个 consumer 来消费。
前提:一个消费者组里面的消费者能同时消费同一个topic的分区数据,但是不能共同消费topic的同一个分区数据。
- Round-Robin:把所有topic的所有分区看作一个整体(通过topicandpartition的hash规则将所有topic的所有分区整合成一个整体),然后进行顺序轮询的方式让消费者组里消费者进行消费。
- 可以让各个消费者均匀的消费到数据,差值仅为1
- 各个消费者必须都订阅了相同的topic,不然把所有的topic的分区作为整体顺序轮询让消费者消费的话,消费者可能会消费到没有订阅的topic的分区数据。
- Range:以topic为分组,将一个topic的所有分区个数 / 消费者组中消费者的个数 将同一个topic的所有分区平均分配到各个消费者让其消费。kafka默认是这种消费模式
- 当topic多的时候,各个消费者不可能很均匀的消费到数据,差值大
- 消费者不会消费到自己没有订阅的topic的消息数据
注意:当消费者组里的消费者个数发生变化时,分区就需要重新分配给消费者进行消费
range消费者分区分配策略案例
消费者消费时offset的维护
由于 consumer 在消费过程中可能会出现断电宕机等故障,consumer 恢复后,需要从故障前的位置的继续消费,所以 consumer 需要实时记录自己消费到了哪个 offset,以便故障恢复后继续消费。
consumer group + Topic + parttion 唯一决定一个offset
Kafka 0.9 版本之前,consumer 默认将 offset 保存在 Zookeeper 中,从 0.9 版本开始, consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中,该 topic 为__consumer_offsets
消费者组案例
需求:测试同一个消费者组中的消费者,同一时刻只能有一个消费者消费
修改消费者组的名字
vim consumer.properties group.id=sunzhaojiang
启动1个生产者,2个消费者,查看两个消费者发现:同一时刻只有一个消费者接收到消息