Kafka 消费者

Kafka: 消费者和消费者组

消费者是通过主题从 Kafka 集群消费或读取数据的消费者。消费者也知道它应该从哪个代理读取数据。消费者按顺序读取每个分区内的数据。这意味着消费者不应该在从偏移量 0 读取数据之前从偏移量 1 读取数据。此外，消费者可以轻松地同时从多个代理读取数据

例如，两个消费者即消费者 1 和消费者 2 正在读取数据。消费者 1 正在按顺序从代理 1 读取数据。另一方面，Consumer 2 同时按顺序从 Broker 2 和 Broker 3 读取数据。

注意: 消费者 2 正在从 Broker 2 和 Broker 3 并行读取数据。因此，Broker 2 下的偏移量 2 与 Broker 3 下的偏移量 2 中包含的数据没有任何联系。

Consumer Groups

Consumer Group 是一个由多个消费者组成的群体，他们基本上是对一个应用程序的愿景。组中的每个消费者直接从独占分区读取数据。如果消费者数量多于分区数量，部分消费者将处于非活动状态。不知何故，如果我们失去了组内任何活跃的消费者，那么不活跃的消费者可以接管并进入活跃状态以读取数据。

但是，如何决定哪个消费者应该先从哪个分区读取数据？

对于这样的决定，组内的消费者会自动使用'GroupCoordinator ' 和一个 'ConsumerCoordinator'，它将消费者分配给一个分区。这个特性已经在 Kafka 中实现了。因此，用户无需担心。

让我们看看下面的示例。

示例 1

考虑两组消费者，即Consumer Group-1 和Consumer Group-2、组 1 的两个消费者一起读取数据，但来自不同的分区。组 1 的两个消费者都将保持活动状态，因为他们正在并行读取数据。

另一方面，Group 2 的Consumer 1 也在从Topic-T 下的Partition 1 读取数据。在这里，消费者也处于活动状态，因为它属于第 2 组。

示例 2

考虑另一种情况，其中一个消费者组有三个消费者。消费者 1 和消费者 2 处于活动状态。消费者 1 正在从分区 0 和消费者 2 从分区 1 读取数据。因此，只有两个主题分区可用，但有三个消费者。因此，消费者 3 将保持非活动状态，直到任何活跃的消费者离开。

注意: 在示例 2 中，三个消费者仅出现在一组中。这就是消费者 3 处于非活动状态的原因。但是，如果消费者存在于另一个组中，它将处于活动状态并能够读取数据。

消费者偏移量

Apache Kafka 提供了一个方便的特性来存储消费者组的偏移值。它存储一个偏移值，以了解消费者组正在哪个分区读取数据。一旦组中的消费者读取数据，Kafka 会自动提交偏移量，或者可以对其进行编程。这些偏移量在名为 __consumer_offsets 的主题中实时提交。此功能是在消费者无法读取数据的机器故障的情况下实现的。因此，由于偏移量的承诺，消费者将能够从上次中断的地方继续阅读。

例如，

在下面图中，消费者组中的消费者正在读取数据。读取数据后，消费者已经提交了偏移量。这意味着下一次，消费者将不会从头读取数据，而是从提交点读取数据。此外，不知何故消费者死亡，它将只能从提交状态继续。

交付语义

承诺的选择取决于消费者，即消费者何时希望提交偏移量。提交偏移量就像读者在阅读书籍或小说时使用的书签。

在 Kafka 中，使用了以下三种传递语义:

最多一次: 这里，消费者一收到消息就提交偏移量..但如果处理不正确，消息就会丢失，消费者将无法进一步阅读。因此，这种语义是最不受欢迎的。

至少一次: 这里，在处理消息后提交偏移量。如果处理出错，则消息将被消费者再次读取。因此，这通常是首选使用。由于消费者可以两次读取消息，因此会导致对消息进行重复处理。因此，它需要一个系统才能成为幂等系统。

恰好一次: 在这里，可以仅使用 Kafka Streams API 为 Kafka 到 Kafka 工作流实现偏移。为了实现 Kafka 到外部系统的偏移，我们需要使用幂等消费者。

下一章：Kafka 用例

Apache Kafka 用例 Apache Kafka 有以下用例最能描述使用它的事件: 1) 消息Broker Apache Kafka 是一种趋势技术，能够处理大量类似类 ...

上一章：Kafka 生产者 Producers

下一章：Kafka 用例