共计 1620 个字符，预计需要花费 5 分钟才能阅读完成。
与生产者对应的是消费者，应用程序能够通过 KafkaConsumer 来订阅主题，并从订阅的主题中拉取音讯。不过在应用 KafkaConsumer 生产音讯之前须要先理解消费者和生产组的概念，否则无奈了解如何应用 KafkaConsumer。
明天先解说消费者与生产组之间的关系，后续再联合案例再粗疏地解说如何应用。
消费者负责订阅 Kafka 中的主题（Topic），并且从订阅的主题上拉取音讯。与其余一些消息中间件不同的是：在 Kafka 的生产理念中还有一层生产组的概念，每个消费者都有一个对应的生产组。当音讯公布到主题后，只会被投递给订阅它的每个生产组中的一个消费者。
如上图所示，某个主题中共有 4 个分区（Partition）：P0、P1、P2、P3。有两个生产组 A 和 B 都订阅了这个主题，生产组 A 中有 4 个消费者（C0、C1、C2 和 C3），生产组 B 中有 2 个消费者（C4 和 C5）。依照 Kafka 默认的规定，最初的调配后果是生产组 A 中的每一个消费者调配到 1 个分区，生产组 B 中的每一个消费者调配到 2 个分区，两个生产组之间互不影响。每个消费者只能生产所调配到的分区中的音讯。换言之，每一个分区只能被一个生产组中的一个消费者所生产。
咱们再来看一下生产组内的消费者个数变动时所对应的分区调配的演变。假如目前某生产组内只有一个消费者 C0，订阅了一个主题，这个主题蕴含 7 个分区：P0、P1、P2、P3、P4、P5、P6。也就是说，这个消费者 C0 订阅了 7 个分区，具体调配情景参考上图。
此时生产组内又退出了一个新的消费者 C1，依照既定的逻辑，须要将原来消费者 C0 的局部分区调配给消费者 C1 生产，如上图所示。消费者 C0 和 C1 各自负责生产所调配到的分区，彼此之间并无逻辑上的烦扰。
消费者与生产组这种模型能够让整体的生产能力具备横向伸缩性，咱们能够减少（或缩小）消费者的个数来进步（或升高）整体的生产能力。对于分区数固定的状况，一味地减少消费者并不会让生产能力始终失去晋升，如果消费者过多，呈现了消费者的个数大于分区个数的状况，就会有消费者调配不到任何分区。参考下图，一共有 8 个消费者，7 个分区，那么最初的消费者 C7 因为调配不到任何分区而无奈生产任何音讯。
以上调配逻辑都是基于默认的分区调配策略进行剖析的，能够通过消费者客户端参数 partition.assignment.strategy 来设置消费者与订阅主题之间的分区调配策略。
对于消息中间件而言，个别有两种音讯投递模式：点对点（P2P，Point-to-Point）模式和公布 / 订阅（Pub/Sub）模式。点对点模式是基于队列的，音讯生产者发送音讯到队列，音讯消费者从队列中接管音讯。
公布订阅模式定义了如何向一个内容节点公布和订阅音讯，这个内容节点称为主题（Topic），主题能够认为是消息传递的中介，音讯发布者将音讯公布到某个主题，而音讯订阅者从主题中订阅音讯。主题使得音讯的订阅者和发布者相互放弃独立，不须要进行接触即可保障音讯的传递，公布 / 订阅模式在音讯的一对多播送时采纳。Kafka 同时反对两种音讯投递模式，而这正是得益于消费者与生产组模型的符合：
- 如果所有的消费者都隶属于同一个生产组，那么所有的音讯都会被平衡地投递给每一个消费者，即每条音讯只会被一个消费者解决，这就相当于点对点模式的利用。
- 如果所有的消费者都隶属于不同的生产组，那么所有的音讯都会被播送给所有的消费者，即每条音讯会被所有的消费者解决，这就相当于公布 / 订阅模式的利用。
生产组是一个逻辑上的概念，它将旗下的消费者归为一类，每一个消费者只隶属于一个生产组。每一个生产组都会有一个固定的名称，消费者在进行生产前须要指定其所属生产组的名称，这个能够通过消费者客户端参数 group.id 来配置，默认值为空字符串。
消费者并非逻辑上的概念，它是理论的利用实例，它能够是一个线程，也能够是一个过程。同一个生产组内的消费者既能够部署在同一台机器上，也能够部署在不同的机器上。
