Kafka详细设计和生态系统

此翻译来自Jean-Paul Azar出版的Kafka详细设计和生态系统。文章中的版权和图像代码数据均属于作者。

为了本地化，翻译内容略有修改。 Kafka 生态系统 - Kafka 核心、Kafka 流、Kafka 连接、Kafka REST 代理和模式注册 Kafka 核心是代理、主题、日志、分区和集群。

核心还包括 MirrorMaker 等相关工具。前面提到的是 Kafka，因为它存在于 Apache 中。

Kafka 生态系统由 Kafka Core、Kafka Streams、Kafka Connect、Kafka REST Proxy 和 Schema Registry 组成。 Kafka 生态系统的其余大部分来自 Confluence，而不是 Apache 的一部分。

Kafka Stream 是一个 Streams API，用于转换、聚合和处理流中的记录并生成派生流。 Kafka Connect 是一个 API 连接器，用于创建可重用的生产者和消费者（例如来自 DynamoDB 的更改流）。

Kafka REST 代理通过 REST (HTTP) 供生产者和消费者使用。模式注册表使用模式管理 AvroKafka 记录。

Kafka MirrorMaker用于将集群数据复制到另一个集群。 Kafka 生态系统：连接源、连接接收器和 Kafka 数据流图 Kafka 连接源是记录的来源。

Kafka 连接接收器是记录的目的地。 Kafka 生态系统：Kafka REST Broker 和 Confluence Schema 注册表 Kafka Streams - 用于流处理的 Kafka Streams Kafka Stream API 构建在核心 Kafka 原语之上，并具有自己的生命力。

Kafka Streams可以实时处理流。 Kafka Streams 支持流处理器。

流处理器从输入主题获取连续的记录流，对输入执行一些处理、转换和聚合，并生成一个或多个输出流。例如，视频播放器应用程序可能会接收观看的视频事件的输入流，暂停视频，并输出用户偏好的流，然后根据最近的用户活动或来自许多用户的聚合活动来获取新的视频推荐，以查看哪些内容。

新视频很火。 Kafka Stream API 解决了无序记录的问题、跨多个流进行聚合、连接来自多个流的数据、允许有状态计算等等。

Kafka 生态系统：Kafka Streams 和 Kafka Connect Kafka 生态系统回顾 什么是 Kafka Streams？ Kafka Streams可以实时处理流。它可以聚合多个流、连接来自多个流的数据、允许状态计算等等。

什么是卡夫卡连接？ Kafka Connect 是一个连接器 API，用于创建可重用的生产者和消费者（例如来自 DynamoDB 的更改流）。 Kafka连接源是记录的来源。

Kafka 连接接收器是记录的目的地。什么是模式注册表？模式注册管理使用 Avro 作为 Kafka 记录管理模式。

什么是Kafka镜像制作器？ Kafka MirrorMaker用于将集群数据复制到另一个集群。什么时候可以使用 Kafka REST 代理？ Kafka REST 代理通过 REST (HTTP) 供生产者和消费者使用。

您可以使用它轻松集成现有的代码库。如果您不确定 Kafka 是什么，请参阅什么是 Kafka？ Kafka架构：底层设计本文是我们Kafka架构系列的一部分，包括Kafka主题架构、Kafka生产者架构、Kafka用户架构和Kafka生态系统架构。

本文的灵感来自于Kafka的设计部分。你可以把它想象成悬崖笔记。

Kafka 的设计动机 LinkedIn 工程师构建 Kafka 来支持实时分析。 Kafka 被设计为一个提供实时流处理的分析系统。

LinkedIn 将 Kafka 开发为用于实时处理流数据源的统一平台。 Kafka背后的目标是构建一个高吞吐量的流数据平台，支持日志聚合、用户活动和其他大容量事件流。

为了满足Kafka的扩展需求，该发行版支持分片和负载均衡。扩展的需求激发了 Kafka 的分区和消费者模型。

Kafka 使用分区、分布式、提交日志来扩展写入和读取。 Kafka 的分片称为分区（Kinesis 与 Kafka 类似，称为分区“分片”）。

根据维基百科的说法，“数据库分片是数据库或搜索引擎中数据的水平分区。每个分区称为分片或数据库分片。

每个分片都保存在单独的数据库服务器实例上以分散负载”。Kafka 的设计目的是处理来自离线系统的定期大数据负载以及具有低延迟的传统消息传递用例；与许多 MOM 一样，Kafka 可以容错节点故障。

和领导人选举。然而，Kafka 的设计更像是一个分布式数据库事务日志，而不是传统的消息系统。

与许多 MOM 不同，Kafka 的复制是建立在底层设计之上的，而不是事后才想到的。持久性：拥抱文件系统 Kafka依靠文件系统来存储和缓存记录。

顺序写入硬盘的性能很快（非常快）。 JBOD 只是一堆磁盘驱动器。

具有 6 rpm SATA RAID-5 阵列的 JBOD 配置约为 MB/秒。与 Cassandra 表一样，Kafka 日志是只写结构，这意味着数据会附加到日志的末尾。

使用硬盘时，顺序读取和写入速度快、可预测，并且可以由操作系统进行大量优化。使用 HDD 时，顺序磁盘访问可能比随机内存访问和 SSD 更快。

虽然 JVM GC 的开销可能很高，但 Kafka 依赖于操作系统上的缓存，这是一个巨大、快速且稳定的缓存。此外，现代操作系统使用所有可用的主内存进行磁盘缓存。

操作系统文件缓存实际上是免费的，没有操作系统开销。实现缓存一致性是正确的挑战，但 Kafka 依靠坚如磐石的操作系统来实现缓存一致性。

使用操作系统进行缓存还可以减少缓冲区副本的数量。由于 Kafka 磁盘使用往往是顺序读取，因此操作系统预读缓存令人印象深刻。

Cassandra、Netty 和 Varnish 使用类似的技术。所有这些都在 Kafka 文档中得到了很好的解释，并且在绘制站点中有一个更有趣的解释。

大容量硬盘和长期访问 Kafka提倡对磁盘进行长期顺序访问进行读写。 Cassandra、LevelDB、RocksDB 等 Kafka 使用日志结构化存储和压缩形式，而不是磁盘上的可变 BTree。

与 Cassandra 一样，Kafka 使用墓碑而不是立即删除记录。由于现在磁盘的空间是无限的，而且速度非常快，Kafka 可以提供消息系统中不常见的功能，例如长时间保留旧消息。

这种灵活性允许 Kafka 进行有趣的应用。 Kafka 生产者负载平衡 生产者向 Kafka 代理询问有关哪个 Kafka 代理拥有哪个主题分区领导者的元数据，因此不需要路由层。

该领导者数据允许生产者将记录直接发送到 Kafka 代理分区领导者。生产者客户端控制将消息发布到哪个分区，并且可以根据某些应用程序逻辑选择分区。

生产者可以按键、循环或使用自定义的特定于应用程序的分区逻辑对记录进行分区。Kafka Producer 日志批量处理 Kafka Producer 支持日志批量处理。

可以通过批次记录的大小来配置批次。批次可以根据时间自动刷新。

批处理对于网络IO吞吐量非常有利，大大提高吞吐量。缓冲是可配置的，允许您牺牲额外的延迟以获得更好的吞吐量。

或者，在系统使用频繁的情况下，它可能会提高平均吞吐量并减少总体延迟。批处理允许累积发送更多字节，相当于减少 Kafka Broker 上的 I/O 操作并提高压缩效率。

为了获得更高的吞吐量，Kafka Producer 配置允许基于时间和大小的缓冲。生产者批量发送多条记录，而不是逐条发送每个记录的网络请求。

Kafka Producer 成分 Kafka 压缩 在大型流媒体平台中，瓶颈并不总是 CPU 或磁盘，而通常是网络带宽。在云中，例如容器化和虚拟化环境，存在更多的网络带宽问题，因为多个服务可能共享一张NiC卡。

此外，与数据中心或 WAN 通信时，网络带宽问题也可能成为问题。批处理有利于高效压缩和网络 IO 吞吐量。

Kafka 提供端到端的批量压缩。 Kafka 不是一次性压缩所有记录，而是有效地压缩整批记录。

同一批消息可以压缩一次并发送到Kafka代理/服务器并以压缩形式写入日志分区。您甚至可以配置压缩，以便在 Kafka 代理将压缩记录交付给用户之前不会对其进行解压缩。

Kafka支持GZIP、Snappy和LZ4压缩协议。拉取与推/流 Kafka 消费者从代理获取数据。

其他系统代理将数据或流数据推送给消费者。消息传递通常是基于拉式的系统（SQS，大多数 MOM 使用拉式）。

在拉动的情况下，如果消费者落后了，它会稍后赶上。由于 Kafka 是基于拉取的，因此它实现了广泛的数据批处理。

Kafka 像许多基于拉取的系统一样实现了长期轮询（SQS、Kafka 都这样做）。长轮询使连接保持打开状态，并在请求后等待一段时间的响应。

基于拉的系统必须拉数据然后对其进行处理。拉取和获取数据之间总是有一个暂停。

将数据推送给消费者（Scribe、Flume、Reactive Streams、RxJava、Akka）。基于推送或流媒体的系统在处理缓慢或死亡的消费者时存在问题。

当消费速度慢于生产速度时，推送系统消费者面临不堪重负的风险。一些基于推送的系统使用基于背压的退避协议，该协议允许消费者表明他们因看到反应流而不知所措。

当尝试跟踪消息确认时，不淹没消费者和消费者恢复的问题很棘手。基于推送或流式传输的系统可以立即发送请求，也可以累积请求并分批发送（或基于背压的组合）。

基于推送的系统总是推送数据。消费者可以在处理已发送数据的同时累积消息，这有助于减少消息处理延迟。

但如果消费者在处理后死亡，那么broker如何知道消费者在哪里以及何时再次将数据发送给其他消费者。这个问题并不容易解决。

Kafka 通过使用拉式系统来解决这些复杂的问题。传统 MOM 使用者消息状态跟踪 对于大多数 MOM，代理负责跟踪哪些消息被标记为已使用。

消息跟踪不是一件容易的事。当消费者消费信息时，经纪人跟踪状态。

大多数 MOM 系统的目标是让经纪商在消费后快速删除数据。请记住，大多数 MOM 是在磁盘较小、功能较弱且昂贵的情况下编写的。

这种消息跟踪比听起来更复杂（确认功能），因为代理必须维护大量状态来跟踪每条消息、发送消息、确认消息并知道何时删除或重新发送消息。 Kafka 消费者消息状态跟踪 请记住，Kafka 主题分为有序分区。

每条消息在此有序分区中都有一个偏移量。每个主题分区一次仅由一个消费者组消费。

这种分区布局的意思是，代理会像 MOM 一样跟踪每条消息跟踪的偏移量数据，但只需要每个用户组的偏移量，这些偏移量是存储的分区偏移量对。这种偏移跟踪相当于要跟踪的数据少得多。

消费者定期向Kafka代理发送位置数据（消费者组、分区偏移对），代理将这些偏移数据存储到偏移主题中。与 MOM 相比，偏移式消息确认要便宜得多。

此外，消费者更加灵活，可以倒回到较早的偏移量（重播）。如果出现错误，则修复错误，倒回消费者并重播主题。

这种回滚功能是 Kafka 的杀手级功能，因为 Kafka 可以长期保存主题日志数据。消息传递语义 存在三种消息传递语义：最多一次、至少一次和恰好一次。

至多一次消息可能会丢失，但永远不会重新发送。至少一次消息永远不会丢失，但可以重新传送。

每条消息只传送一次。准确地说，它曾经是首选，但价格更高，并且需要生产者和消费者进行更多记账。

Kafka 消费者和消息传递语义回想一下，所有副本都具有完全相同的日志分区和相同的偏移量，并且用户组在每个主题分区的日志中维护其位置。为了实现“最多一次”，消费者读取消息，然后将其偏移量保存在分区中并将其发送到代理，最后由代理处理该消息。

“最多一次”的问题是消费者可能会在保存其位置之后但在处理消息之前死亡。接管或重新启动的消费者将留在最后的位置，并且不会处理有问题的消息。

要做到“至少一次”，消费者读取消息，处理消息，最后将成本节省给broker。 “至少一次”的问题是消费者可能会在处理消息之后但在保存最后一个偏移位置之前崩溃。

然后，如果该消费者重新启动或另一个消费者接管，该消费者就可以收到处理后的消息。 “至少一次”是最常见的消息传递设置，您的责任是使消息幂等，这意味着两次获取相同的消息不会导致问题（两次借方）。

为了在消费者端实现“恰好一次”，消费者需要在消费者位置的存储和消费者消息处理输出的存储之间进行两阶段提交。或者，消费者可以将消息处理输出存储在与最后一个偏移量相同的位置。

Kafka 提供了前两个，从消费者的角度来看，实现了第三个。 Kafka 生产者的持久性和确认 Kafka 为持久性提供了操作可预测性语义。

当消息发布时，它被“提交”到日志中，这意味着所有 ISR 都接受该消息。只要至少存在一个副本，这种提交策略就可以很好地实现持久性。

生产者连接可能会在发送过程中断开，生产者可能不确定其发送的消息是否已通过，然后生产者会重新发送消息。这种重传逻辑就是为什么使用消息密钥和使用幂等消息（重复确定性）如此重要的原因。

Kafka 最近（2018 年 6 月）才保证消息不会从生产者重试中复制。生产者可以重新发送消息，直到收到确认，即收到确认。

生产者重新发送消息而不知道它是否发送了其他消息，从而否定了“恰好一次”和“最多一次”消息传递语义。生产者耐久性 生产者可以指定耐久性级别。

生产者可以等待提交消息。等待提交可确保所有副本都有消息的副本。

生产者无需确认即可发送 (0)。生产者可以获得分区领导者的确认 (1)。

生产者可以发送并等待所有副本的确认（-1），这是默认设置。改进的生产者（6 月版本）Kafka 现在支持生产者的“恰好一次”交付、性能改进和跨分区的原子写入。

他们通过发送序列 ID 的生产者来实现这一点，代理跟踪生产者是否已经发送了该序列，如果生产者尝试再次发送序列，它会收到重复消息的确认，但不会将任何内容保存到生产者中。日志。

此改进不需要更改 API。Kafka 生产者原子日志（2020 年 6 月发布） Kafka 的另一个改进是 Kafka 生产者对原子笔画进行拆分。

原子写入意味着 Kafka 用户只能看到提交日志（这是可配置的）。 Kafka 有一个协调器，它将标记写入主题日志以指示已成功处理的内容。

事务协调器和事务日志维护原子写入的状态。原子写入确实需要新的生产者 API 来处理事务。

以下是使用新生产者 API 的示例。新的生产者API事务代码语言：java copy Producer.initTransaction();尝试 { 生产者.beginTransaction();生产者.send(debitAccountMessage);生产者.send(creditOtherAccountMessage);生产者.sentOffsetsToTxn(...); Producer .commitTransaction();} catch (ProducerFencedTransactionException pfte) { ... Producer.close();} catch (KafkaException ke) { ... Producer.abortTransaction();} Kafka 复制 通过可配置数量的 Kafka 代理进行 Kafka 复制每个主题的分区。

Kafka 的复制模式是默认的，而不是像大多数 MOM 那样的插入功能，因为 Kafka 从一开始就打算与分区和多个节点一起工作。每个主题分区都有一个领导者和零个或多个追随者。

领导者和追随者称为副本。复制因子是领导节点加上所有追随者。

分区领导权在 Kafka 代理之间平等共享。消费者只能阅读领导者的信息。

制作人只写信给领导。 follower的主题日志分区与leader的日志同步，ISR是leader的精确副本减去需要复制的正在进行的记录。

追随者就像普通的 Kafka 消费者一样，从领导者那里批量获取记录。 Kafka Broker 故障转移 Kafka 记录哪些 Kafka Broker 仍处于活动状态。

为了保持活动状态，Kafka Broker 必须使用 ZooKeeper 的心跳机制来维护 ZooKeeper 会话，并且必须使所有追随者与领导者保持同步，而不会落后太多。 ZooKeeper 会话和同步是代理生存所必需的，称为同步。

同步副本称为 ISR。每个领导者都跟踪一组“同步副本”。

如果 ISR/follower 死亡并落后，leader 会将 follower 从 ISR 中移除。当副本在replica.lag.time.max.ms 周期之后变得不同步时，就会落后。

当所有 ISR 都将消息应用到其日志时，该消息被视为“已提交”。消费者只能看到提交的消息。

Kafka保证只要有至少一个ISR，承诺的信息就不会丢失。复制日志分区 Kafka 分区是复制日志。

复制日志是分布式数据系统原语。复制日志对于使用状态机实现其他分布式系统非常有用。

复制日志模型“同意”有序的值序列。当领导者还活着时，所有追随者只需要复制其领导者的价值观和秩序即可。

如果领导者死亡，卡夫卡会从同步的追随者中选择一个新的领导者。如果生产者被告知消息已提交，然后领导者失败，则新当选的领导者必须拥有已提交的消息。

你拥有的 ISR 越多；当领导失败时，就会有更多的选举。 Kafka 和仲裁 仲裁是所需的确认数量以及必须与当选领导者进行比较以确保可用性重叠的日志数量。

大多数系统使用多数投票，Kafka不使用简单多数投票来提高可用性。在 Kafka 中，领导者选择是基于完整的日志。

如果我们的复制因子为 3，那么在领导者发送的消息声明被提交之前，至少有两个 ISR 必须同步。如果需要选举新的领导者并且失败次数不超过3次，则保证新的领导者拥有所有已提交的信息。

在关注者中，必须至少有一个副本包含所有已提交的消息。大多数与仲裁有关的投票问题是没有太多故障并且存在无法运行的集群。

Kafka Quorum ISR Kafka 为每个领导者维护一组 ISR。只有这组 ISR 的成员才有资格领导选举。

在所有 ISR 确认写入之前，生产者写入分区的内容不会被提交。只要 ISR 设置发生更改，ISR 就会持续存在于 ZooKeeper 中。

只有属于 ISR 成员的副本才有资格当选领导者。这种 ISR 仲裁允许生产者在没有大多数节点的情况下继续工作，但只有 ISR 多数投票。

这种类型的 ISR 仲裁还允许副本重新加入 ISR 集并拥有其投票计数，但在加入之前必须完全重新同步，即使副本在崩溃期间丢失了未刷新的数据。所有节点同时死亡。

该怎么办？ Kafka 对数据丢失的保证仅在至少一个副本同步时才有效。如果复制分区领导者的所有追随者立即死亡，则数据丢失 Kafka 保证无效。

如果分区的所有副本都已关闭，则默认情况下 Kafka 会选择第一个处于活动状态的副本（不一定在 ISR 集中）作为领导者（默认情况下配置 unclean.leader.election.enable = true ）。此选择有利于可用性一致性。

如果对于您的用例来说，一致性比可用性更重要，那么您可以设置配置 unclean.leader.election.enable=false ，这样如果所有副本都停止运行分区，Kafka 将等待第一个 ISR 成员（而不是第一个 ISR 成员）。第一个副本）变得活跃以选举新的领导者。

生产者选择持久性 生产者可以通过设置 ack (0)、仅引导 (1) 或所有副本 (-1) 来选择持久性。 acks = all 是默认值。

总而言之，当所有当前同步副本 (ISR) 收到消息时，就会发生这种情况。您可以在一致性和可用性之间进行权衡。

如果持久性超过可用性，请禁用不干净的领导者选举并指定最小 ISR 大小。最小ISR大小越大，一致性保证得越好。

但是，如果ISR集的大小小于最小阈值，则ISR的最小ISR越高，可用性越低，因为分区将不可用。配额 Kafka 为消费者和生产者建立了配额，限制了他们可以消耗的带宽。

这些配额可防止消费者或生产者占用 Kafka 代理资源。配额由客户端 ID 或用户确定。

配额数据存储在ZooKeeper中，因此更改不需要重新启动Kafka代理。 Kafka 底层设计和架构回顾 如何防止来自写得不好的消费者的拒绝服务攻击？使用配额来限制消费者带宽。

默认的生产者持久性 (ack) 级别是多少？全部。这意味着所有 ISR 必须将消息写入其日志分区。

如果所有 Kafka 节点同时宕机，默认情况下会发生什么？ Kafka 选择第一个副本（不一定在 ISR 集中）作为领导者，unclean.leader.election.enable=true 以支持可用性。为什么 Kafka 记录批处理很重要？通过线路和磁盘优化 IO 吞吐量。

它还通过压缩整个批次来提高压缩效率。 Kafka 的一些设计目标是什么？成为高吞吐量、可扩展的流数据平台，用于实时分析日志聚合、用户活动等大容量事件流。

截至今年 6 月，Kafka 有哪些新功能？生产者以原子方式写入，性能得到提高，并且生产者不会发送重复的消息。有哪些不同的消息传递语义？消息传递语义分为三种：最多一次、至少一次和恰好一次。