关于kafka:一文教你理解Kafka-offset

191次阅读

共计 3563 个字符,预计需要花费 9 分钟才能阅读完成。

日常开发中,置信大家都对 Kafka 有所耳闻,Kafka 作为一个分布式的流解决平台,个别用来存储和传输大量的音讯数据。在 Kafka 中有三个重要概念,别离是 topic、partition 和 offset。

  • topic 是 kafka 中的音讯以主题为单位进行归类的逻辑概念,生产者负责将音讯发送到特定的主题,消费者负责订阅主题并进行生产。
  • partition 是 topic 的物理概念,每个 topic 能够细分为多个 partition,每个 partition 只属于单个 topic,并且蕴含不同的音讯,partition 用于进步 topic 的存储和生产的性能和可扩展性,能够将 topic 扩散在多个 broker 上,并反对多个 consumer 并行生产。
  • offset 是 partition 中每条音讯的惟一标识,是一个枯燥递增且不变的值,由 kafka 主动保护,offset 用于定位和记录音讯在 partition 中的地位和生产进度,保障 partition 内的音讯有序。

本文将给大家介绍 offset 的相干概念, 纲要如下

  • offset 的作用和意义
  • offset 的存储和治理
  • offset 的提交和重置
  • offset 的生产和保障

offset 的作用和意义

offset 是 Kafka 为每条音讯调配的一个惟一的编号,它示意音讯在分区中的程序地位。offset 是从 0 开始的,每当有新的音讯写入分区时,offset 就会加 1。offset 是不可变的,即便音讯被删除或过期,offset 也不会扭转或重用。

offset 的作用次要有两个:

  • 一是用来定位音讯。通过指定 offset,消费者能够精确地找到分区中的某条音讯,或者从某个地位开始生产音讯。
  • 二是用来记录生产进度。消费者在生产完一条音讯后,须要提交 offset 来通知 Kafka broker 本人生产到哪里了。这样,如果消费者产生故障或重启,它能够依据保留的 offset 来复原生产状态。

offset 的存储和治理

offset 的存储和治理次要波及到两个方面:生产者端和消费者端。

生产者端

生产者在向 Kafka 发送音讯时,能够指定一个分区键(Partition Key),Kafka 会依据这个键和分区算法来决定音讯应该发送到哪个分区。如果没有指定分区键,Kafka 会采纳轮询或随机的形式来抉择分区。生产者也能够自定义分区算法。

当音讯被写入到分区后,Kafka broker 会为音讯调配一个 offset,并返回给生产者。生产者能够依据返回的 offset 来确认音讯是否胜利写入,并进行重试或其余解决。

消费者端

消费者在生产 Kafka 音讯时,须要保护一个以后生产的 offset 值,以及一个已提交的 offset 值。以后生产的 offset 值示意消费者正在生产的音讯的地位,已提交的 offset 值示意消费者曾经确认生产过的音讯的地位。

消费者在生产完一条音讯后,须要提交 offset 来更新已提交的 offset 值。提交 offset 的形式有两种:主动提交和手动提交。

  • 主动提交:Kafka 提供了一个配置参数 enable.auto.commit,默认为 true,示意开启主动提交性能。主动提交性能会在后盾定期(由 auto.commit.interval.ms 参数管制)将以后生产的 offset 值提交给 Kafka broker。
  • 手动提交:如果 enable.auto.commit 设置为 false,则示意敞开主动提交性能,此时消费者须要手动调用 commitSync 或 commitAsync 办法来提交 offset。手动提交性能能够让消费者更灵便地管制何时以及如何提交 offset。

无论是主动提交还是手动提交,offset 的理论存储地位都是在 Kafka 的一个内置主题中:__consumer_offsets。这个主题有 50 个分区(可配置),每个分区存储一部分生产组(Consumer Group)的 offset 信息。Kafka broker 会依据生产组 ID 和主题名来计算出一个哈希值,并将其映射到 __consumer_offsets 主题的某个分区上。

__consumer_offsets 主题是 Kafka 0.9.0 版本引入的新个性,之前的版本是将 offset 存储在 Zookeeper 中。然而 Zookeeper 不适宜大量写入,因而起初改为存储在 Kafka 本身中,进步了性能和可靠性。

offset 的提交和重置

提交 offset 是消费者在生产完一条音讯后,将以后生产的 offset 值更新到 Kafka broker 中的操作。提交 offset 的目标是为了记录生产进度,以便在消费者产生故障或重启时,可能从上次生产的地位持续生产。

重置 offset 是消费者在启动或运行过程中,将以后生产的 offset 值批改为其余值的操作。重置 offset 的目标是为了调整生产地位,以便在须要从新生产或跳过某些音讯时,可能实现这个需要。

提交 offset

提交 offset 的形式有两种:主动提交和手动提交。后面曾经介绍过这两种形式的区别和用法,这里不再赘述。须要留神的是,无论是主动提交还是手动提交,都不保障提交胜利。因为 Kafka broker 可能产生故障或网络提早,导致提交失败或提早。因而,消费者须要解决提交失败或提早的状况。

  • 提交失败:如果提交失败,消费者能够抉择重试或放弃。重试的话,可能会导致屡次提交同一个 offset 值,然而不会影响正确性,因为 Kafka broker 会疏忽反复的 offset 值。放弃的话,可能会导致下次启动时从新生产曾经生产过的音讯,然而不会影响完整性,因为 Kafka 音讯是幂等的。
  • 提交提早:如果提交提早,消费者能够抉择期待或持续。期待的话,可能会导致生产速度变慢,或者超过 session.timeout.ms 参数设置的工夫而被认为曾经死亡。持续的话,可能会导致下次启动时漏掉一些没有提交胜利的音讯。

重置 offset

重置 offset 的形式有两种:手动重置和主动重置。手动重置是指消费者被动调用 seek 或 seekToBeginning 或 seekToEnd 办法来批改以后生产的 offset 值。主动重置是指消费者在启动时依据 auto.offset.reset 参数来决定从哪个地位开始生产。

  • 手动重置:手动重置能够让消费者准确地管制从哪个地位开始生产。例如,如果想要从新生产某个分区的所有音讯,能够调用 seekToBeginning 办法将 offset 设置为 0;如果想要跳过某个分区的所有音讯,能够调用 seekToEnd 办法将 offset 设置为最大值;如果想要从某个具体的地位开始生产,能够调用 seek 办法将 offset 设置为任意值。
  • 主动重置:主动重置能够让消费者在启动时依据 auto.offset.reset 参数来决定从哪个地位开始生产。auto.offset.reset 参数有三个可选值:earliest, latest 和 none。earliest 示意从最早的可用音讯开始生产;latest 示意从最新的可用音讯开始生产;none 示意如果没有可用的 offset,则抛出异样。

offset 的生产和保障

offset 的生产和保障次要波及到两个方面:程序性和一致性。

程序性

程序性是指 Kafka 音讯是否依照发送和接管的程序进行解决。Kafka 只保障分区内的程序性,即同一个分区内的音讯依照 offset 的程序进行发送和接管。然而不保障主题内或跨主题的程序性,即不同分区内的音讯可能会乱序发送和接管。因而,如果须要保障主题内或跨主题的程序性,须要在生产者和消费者端进行额定的解决,例如应用同一个分区键或同一个生产组。

一致性

一致性是指 Kafka 音讯是否可能被正确地发送和接管,不会呈现失落或反复的状况。Kafka 提供了三种不同级别的一致性保障:最多一次(At most once),起码一次(At least once)和准确一次(Exactly once)。

  • 最多一次:最多一次是指 Kafka 音讯只会被发送或接管一次或零次,不会呈现反复的状况,然而可能会呈现失落的状况。这种保障的实现形式是在生产者端敞开重试性能,在消费者端在生产音讯之前提交 offset。这种保障实用于对音讯失落不敏感的场景,例如日志收集或监控。
  • 起码一次:起码一次是指 Kafka 音讯只会被发送或接管一次或屡次,不会呈现失落的状况,然而可能会呈现反复的状况。这种保障的实现形式是在生产者端开启重试性能,在消费者端在生产音讯之后提交 offset。这种保障实用于对音讯反复不敏感的场景,例如计数或累加。
  • 准确一次:准确一次是指 Kafka 音讯只会被发送或接管一次,不会呈现失落或反复的状况。这种保障的实现形式是在生产者端和消费者端应用事务性能,在消费者端应用幂等性能。这种保障实用于对音讯失落和反复都敏感的场景,例如转账或领取。

最初,心愿本文可能对您了解 kafka offset 有所帮忙,感激浏览。

正文完
 0