kafka的消费模型

前言

读完本文，你将了解到如下知识点。

1. kafka的消费模型选型
2. kafka的消费组模式以及高可用机制
3. kafkaClient拉取消息的内部实现机制

消费模型选型

消息由生产者发送到kafka集群后，会被消费者消费。一般来说我们的消费模型有两种:推送模型(psuh)和拉取模型(pull)。当然，kafka这里选取了pull的方式，下面阐述下原因。

1. push无法很好地保证消费的处理语义,比如当我们把已经把消息发送给消费者之后，由于消费进程挂掉或者由于网络原因没有收到这条消息，如果我们在消费代理将其标记为已消费，这个消息就永久丢失了。
2. 如果采用push，消息消费的速率就完全由消费代理控制，消费者的消费能力降低时，消费代理无法感知，一旦消费者发生阻塞，就会出现问题。
3. Kafka采取拉取模型(poll)，由自己控制消费速度，以及消费的进度，消费者可以按照任意的偏移量进行消费。 比如消费者可以消费已经消费过的消息进行重新处理，或者消费最近的消息等等。

消费组模式

消费组模式应该是我们在实际开发过程中使用最多的一种消费方式。下面介绍下消费组的特点。

1. 我们可以创建 N 个消费者实例（new KafkaConsumer()）,而且这些实例可以跨进程，当这些实例都用同一个 group.id 来创建时，他们就属于同一个消费组。
2. 在同一个消费组中的消费实例可以收到消息，但一个分区的消息只会发往一个消费实例。
3. 一个topic可以被多个消费组消费，每个消费组消费的数据是互不干扰的，消费进度也各自独立。这让使用也更加灵活，一份数据我们可以用来做各种各样不同场景的分析计算，而且互不影响。

 

高可用机制

高可用的本质其实就是基于消费组的Rebalance。意思就是当我们选用消费组的方式进行消费时，当一些异常的场景出现，我们的消费任务不会异常退出，在经过一系列的重平衡操作后，我们的消费任务得以正常进行。

• 消费组中新增消费实例。
• 消费组中消费实例 down 掉。
• 订阅的Topic分区数发生变化(增删分区)。
• 如果是正则订阅Topic，匹配的Topic数发生变化。

监控业务现在线上正在跑的etl任务就经常可能会碰到重平衡的场景，比如说我现在etl的大topic有400个分区，现在起了100个消费者在消费，按照默认的分区分配策略，每个消费者会平均分配到4个分区，但是当出现消费延迟时，我们需要水平扩容，那可能的处理方式就是我再追加100个消费者，那么每个消费者就会分配到2个分区，提高吞吐。

重平衡协议

1. JointGroup:consumer请求加入组，consumer->协调者(kafka server的coordinator节点)。
2. LeaveGroup:consumer主动请求离开组，consumer->协调者。
3. DescribeGroup:描述组信息如成员/订阅信息/分配方案，管理员->协调者。
4. SyncGroup:群主（第一个加入的consumer）把分配方案同步到组内所有成员，consumer LEADER->协调者->All consumer。
5. HeartBeat:consumer定期向协调者发送心跳，表明自己依然运行。每个consumer根据心跳响应中是否包含重平衡标注决定是否开启新一轮平衡。consumer->协调者。

kafkaClient拉取消息

主体流程：

1. 如果缓存里面有未读取的消息，直接返回这些消息；
2. 构造拉取消息请求，并发送；
3. 发送网络请求并拉取消息，等待直到有消息返回或者超时；
4. 返回拉到的消息。
5. fetcher.fetchedRecords会将返回的Response反序列化，返回给调用者。

具体发送操作由fetcher.sendFetches()实现，主要包括如下步骤：

1. 构造拉取消息请求Request对象
2. 调用ConsumerNetworkClient#send方法异步发送Request
3. 这个send方法将会把kafka节点信息&请求存放到ConsumerNetworkClient#unsent成员变量中
4. 注册一个回调类来处理返回的Response
5. Response暂时被存放在Fetcher#completedFetches成员变量中
6. 当调用ConsumerNetworkClient#poll方法时，才会遍历unsent，将其中的请求发出去，并处理收到的Response。
    

流程序列图