kafka多个消费者消费一个topic_kafka：一文读懂消费者背后的那点quot;猫腻quot;

来自：z小赵

前言

经过前几篇文章的介绍，大致了解了生产者背后的运行原理。消息有生产就得有人去消费，今天我们就来介绍下消费端消费消息背后发生的那点事儿。

文章概览

消费者与消费组的“父子关系”。
Repartition 触发时机。
消费者与 ZK 的关系。
消费端工作流程。
消费者的三种消费情况。

消费者与消费组的“父子关系”

Kafka 消费端确保一个 Partition 在一个消费者组内只能被一个消费者消费。这句话改怎么理解呢？

在同一个消费者组内，一个 Partition 只能被一个消费者消费。
在同一个消费者组内，所有消费者组合起来必定可以消费一个 Topic 下的所有 Partition。
在同一个消费组内，一个消费者可以消费多个 Partition 的信息。
在不同消费者组内，同一个分区可以被多个消费者消费。
每个消费者组一定会完整消费一个 Topic 下的所有 Partition。

消费组存在的意义

了解了消费者与消费组的关系后，有朋友会比较疑惑消费者组有啥实际存在的意义呢？或者说消费组的作用是什么？

作者对消费组的作用归结了如下两点。

在实际生产中，对于同一个 Topic，可能有 A、B、C 等 N 个消费方想要消费。比如一份用户点击日志，A 消费方想用来做一个用户近 N 天点击过哪些商品；B 消费方想用来做一个用户近 N 天点击过前 TopN 个相似的商品；C 消费方想用来做一个根据用户点击过的商品推荐相关周边的商品需求。对于多应用场景，就可以使用消费组来隔离不同的业务使用场景，从而达到一个 Topic 可以被多个消费组重复消费的目的。
消费组与 Partition 的消费进度绑定。当有新的消费者加入或者有消费者从消费组退出时，会触发消费组的 Repartition 操作(后面会详细介绍 Repartition)；在 Repartition 前，Partition1 被消费组的消费者 A 进行消费，Repartition 后，Partition1 消费组的消费者 B 进行消费，为了避免消息被重复消费，需要从消费组记录的 Partition 消费进度读取当前消费到的位置(即 OffSet 位置)，然后在继续消费，从而达到消费者的平滑迁移，同时也提高了系统的可用性。

Repartition 触发时机

使用过 Kafka 消费者客户端的同学肯定知道，消费者组内偶尔会触发 Repartition 操作，所谓 Repartition 即 Partition 在某些情况下重新被分配给参与消费的消费者。基本可以分为如下几种情况。

消费组内某消费者宕机，触发 Repartition 操作，如下图所示。

消费组内新增消费者，触发 Repartition 操作，如下图所示。一般这种情况是为了提高消费端的消费能力，从而加快消费进度。

Topic 下的 Partition 增多，触发 Repartition 操作，如下图所示。一般这种调整 Partition 个数的情况也是为了提高消费端消费速度的，因为当消费者个数大于等于 Partition 个数时，在增加消费者个数是没有用的(原因是：在一个消费组内，消费者:Partition = 1:N，当 N 小于 1 时，相当于消费者过剩了)，所以一方面增加 Partition 个数同时增加消费者个数可以提高消费端的消费速度。

消费者与 ZK 的关系

众所周知，ZK 不仅保存了消费者消费 partition 的进度，同时也保存了消费组的成员列表、partition 的所有者。消费者想要消费 Partition，需要从 ZK 中获取该消费者对应的分区信息及当前分区对应的消费进度，即 OffSert 信息。那么 Partition 应该由那个消费者进行消费，决定因素有哪些呢？从之前的图中不难得出，两个重要因素分别是：消费组中存活的消费者列表和 Topic 对应的 Partition 列表。通过这两个因素结合 Partition 分配算法，即可得出消费者与 Partition 的对应关系，然后将信息存储到 ZK 中。Kafka 有高级 API 和低级 API，如果不需要操作 OffSet 偏移量的提交，可通过高级 API 直接使用，从而降低使用者的难度。对于一些比较特殊的使用场景，比如想要消费特定 Partition 的信息，Kafka 也提供了低级 API 可进行手动操作。

消费端工作流程

在介绍消费端工作流程前，先来熟悉一下用到的一些组件。

KakfaConsumer：消费端，用于启动消费者进程来消费消息。
ConsumerConfig：消费端配置管理，用于给消费端配置相关参数，比如指定 Kafka 集群，设置自动提交和自动提交时间间隔等等参数，都由其来管理。
ConsumerConnector：消费者连接器，通过消费者连接器可以获得 Kafka 消息流，然后通过消息流就能获得消息从而使得客户端开始消费消息。

以上三者之间的关系可以概括为：消费端使用消费者配置管理创建出了消费者连接器，通过消费者连接器创建队列(这个队列的作用也是为了缓存数据)，其中队列中的消息由专门的拉取线程从服务端拉取然后写入，最后由消费者客户端轮询队列中的消息进行消费。具体操作流程如下图所示。

我们在从消费者与 ZK 的角度来看看其工作流程是什么样的？

从上图可以看出，首先拉取线程每拉取一次消息，同步更新一次拉取状态，其作用是为了下一次拉取消息时能够拉取到最新产生的消息；拉取线程将拉取到的消息写入到队列中等待消费消费线程去真正读取处理。消费线程以轮询的方式持续读取队列中的消息，只要发现队列中有消息就开始消费，消费完消息后更新消费进度，此处需要注意的是，消费线程不是每次都和 ZK 同步消费进度，而是将消费进度暂时写入本地。这样做的目的是为了减少消费者与 ZK 的频繁同步消息，从而降低 ZK 的压力。