Kafka Documentation

概述

Kafka是一个发布订阅系统,当前版本为2.1

介绍

流平台有三个关键功能：
发布和订阅记录流，类似于消息队列或企业消息传递系统；
以容错、持久的方式存储记录流；
当记录发生时，处理记录流。
Kafka通常用于两大类应用程序：
构建可靠地在系统之间获取数据的实时流数据管道；
或构建转换数据流或对数据流作出反应的实时流应用程序。
为了了解Kafka是如何做这些事情的，让我们深入探讨Kafka自下而上的能力。
首先是几个概念：
Kafka在一个或多个可以跨多个数据中心的服务器上运行为群集；
Kafka群集将记录流存储在名为主题的类别中；
每个记录都由一个密钥、一个值和一个时间戳组成。
Kafka有四个核心API：
Producer API允许应用程序将记录流发布到一个或多个Kafka主题。
Consumer API允许应用程序订阅一个或多个主题，并处理向其生成的记录流。
Streams API 允许应用程序充当流处理器，从一个或多个主题消耗输入流，并产生输出流到一个或多个输出主题，从而有效地将输入流转换为输出流。
Connector API允许构建和运行可重用的生产者或使用者，将Kafka主题连接到现有的应用程序或数据系统。例如，连接到关系数据库的连接器可能捕获对表的每一项更改。
在Kafka，客户机和服务器之间的通信是用简单、高性能、语言不可知的TCP协议来完成的。此协议是版本化的，并保持与旧版本的后向兼容性。我们为Kafka提供了一个Java客户端，但客户端可以用多种语言提供。

Topics and Logs

让我们首先深入研究Kafka为记录流提供的核心抽象-主题。
主题是将记录发布到的类别或提要名称。Kafka中的主题总是多订阅者；也就是说，一个主题可以有零、一个或多个订阅写入它的数据的使用者。
对于每个主题，Kafka集群维护一个分区日志，如下所示：

每个分区都是一个有序的、不可变的记录序列，这些记录被不断地附加到一个结构化提交日志中。分区中的记录被分配给一个名为偏移量的顺序id号，它唯一地标识分区内的每个记录。
Kafka集群使用可配置的保留期，持久地保存所有已发布的记录-无论它们是否已被消耗。例如，如果保留策略设置为两天，则在记录发布后的两天内，它可供消费，之后将被丢弃以腾出空间。Kafka的性能在数据大小上实际上是恒定的，因此长时间存储数据并不是一个问题。

事实上，在每个使用者的基础上保留的唯一元数据是该使用者在日志中的偏移量或位置。此偏移量由使用者控制：通常，使用者在读取记录时会线性地推进其偏移量，但事实上，由于该位置由使用者控制，它可以按它喜欢的任何顺序使用记录。例如，使用者可以重置为旧的偏移量来重新处理过去的数据，或者跳到最近的记录，然后从“现在”开始消费。
这种功能的结合意味着Kafka消费者非常便宜-他们可以来来去去，而不会对集群或其他消费者造成太大影响。例如，您可以使用我们的命令行工具来“跟踪”任何主题的内容，而无需更改任何现有使用者所使用的内容。
日志中的分区有几种用途。首先，它们允许日志扩展到适合于单个服务器的大小之外。每个单独的分区必须适合承载它的服务器，但是一个主题可能有许多分区，因此它可以处理任意数量的数据。第二，它们充当并行性的单位-更详细地介绍一下。

Distribution

日志的分区分布在Kafka集群中的服务器上，每个服务器处理数据和分区共享请求。为了容错，每个分区都在可配置的多个服务器上进行复制。
每个分区有一个服务器充当“领导者”，零个或多个服务器充当“追随者”。领导者处理分区的所有读写请求，而跟随者则被动地复制领导。如果领导失败，其中一个追随者将自动成为新的领导。每个服务器都充当一些分区的领导者和其他分区的跟随者，因此负载在集群中是很好的平衡。

Geo-Replication

卡夫卡MirrorMaker为您的群集提供了geo-replication支持。通过MirrorMaker，可以跨多个数据中心或云区域复制消息。您可以在主动/被动场景中使用此选项进行备份和恢复；或在活动/活动方案中，将数据更靠近您的用户，或支持数据局部性要求。

Producers

生产者向他们选择的主题发布数据。生产者负责选择要分配给主题中的哪个分区的记录。这可以循环方式完成，只需平衡负载，也可以根据某些语义分区函数(例如，基于记录中的某个键)来完成。更多在于一秒内分区的使用！

Consumers

使用者用使用者组名称给自己贴上标签，而发布到主题的每条记录都被传递给每个订阅的使用者组中的一个使用者实例。使用者实例可以在单独的进程中，也可以在不同的机器上。
如果所有使用者实例都具有相同的使用者组，那么记录将有效地在使用者实例上被负载平衡。
如果所有的使用者实例都有不同的使用者组，那么每个记录将被广播到所有使用者进程。

一个有两个服务器Kafka的集群托管四个分区（P0-P3）和两个用户组。消费者组A具有两个消费者实例并且组B具有四个。
然而，更常见的是，我们发现，主题有少量的消费群体，每个"逻辑用户"都有一个。每个组都由许多针对可扩展性和容错的消费者实例组成。这不是发布-订阅
语义，其中订阅者是消费者的群集而不是单个过程。
在Kafka中实现的方式是通过在用户实例上划分日志中的分区，以便每个实例都是在任何时间点的分区"公平份额"的独占用户。在该组中维护成员资格的过程由KAFKA协议动态地处理。如果新实例加入该组，则它们将从该组的其他成员接管某些分区；如果实例死亡，则其分区将被分配给其余实例。Kafka仅提供分区中记录的总顺序，而不是主题中的不同分区之间的记录。每个分区排序和按键分区数据的能力对于大多数应用来说是足够的。但是，如果需要对记录的总排序，则这可通过仅有一个分区的主题来实现，尽管这将仅意味着每个消费者组的一个消费者进程。

Multi-tenancy

你可以将Kafka部署为多租户解决方案。通过配置可以生成或使用数据的主题，可以启用多租户。此外，还为配额提供业务支持。管理员可以对控制客户端使用的代理资源的请求定义和强制执行配额。有关更多信息，请参见安全文档。

Guarantees

在高级别上，Kafka提供了以下保证：
由生产者发送到特定主题分区的消息将按发送顺序追加。也就是说，如果记录M1是由记录M2的同一个生产者发送的，并且首先发送的是M1，那么M1的偏移量将低于M2，并且出现在日志的前面。
使用者实例按记录在日志中的存储顺序查看记录。
对于具有复制因子N的主题，我们将容忍最多n-1服务器故障，而不会丢失提交给日志的任何记录。
有关这些保证的更多细节见文档的设计部分。

Kafka as a Messaging System

Kafka关于流的概念与传统的企业消息传递系统相比如何？
消息传递传统上有两种模型：排队和发布-订阅。在队列中，用户池可以从服务器读取，每条记录都被发送到其中一条；在发布-订阅中，记录被广播给所有消费者。这两种模式各有优缺点。排队的优势在于它允许你将数据处理划分到多个使用者实例上，这使您可以扩展处理。不幸的是，队列不是多订阅者-一旦一个进程读取了数据，它就消失了。发布-订阅允许将数据广播到多个进程，但由于每条消息都发送到每个订阅服务器，因此无法扩展处理。
Kafka的消费群体概念概括了这两个概念。与队列一样，使用者组允许你将处理划分为进程的集合(使用者组的成员)。与发布订阅一样，Kafka允许你向多个消费群体广播消息。
Kafka模型的优点在于，每个主题都有这两种特性-它既可以缩放处理，也可以是多用户-没有必要选择其中一种或另一种。
Kafka也比传统的短信系统有更强的订购保证。
传统队列按顺序在服务器上保留记录，如果多个使用者从队列中消费记录，则服务器按照存储的顺序分发记录。但是，虽然服务器按顺序分发记录，但记录是异步传递给使用者的，因此它们可能会在不同的使用者上出现故障。这实际上意味着记录的排序在并行消费的存在下丢失。消息传递系统通常通过一个只允许一个进程从队列中使用的“独占使用者”的概念来解决这个问题，但这当然意味着在处理中没有并行性。
Kafka做得更好。通过在主题中具有并行性-分区-的概念，Kafka能够为用户进程池提供排序保证和负载平衡。这是通过将主题中的分区分配给使用者组中的使用者来实现的，这样每个分区就会被组中的一个消费者使用。通过这样做，我们确保使用者是该分区的唯一读者，并按顺序使用数据。由于有许多分区，这仍然平衡了许多使用者实例的负载。但是，请注意，在使用者组中不能有比分区更多的使用者实例。

Kafka as a Storage System

任何允许发布与使用消息分离的消息队列都有效地充当了在役消息的存储系统。Kafka的不同之处在于它是一个非常好的存储系统。
写入Kafka的数据被写入磁盘并复制以实现容错。Kafka允许生产者等待确认，这样写就不会被认为是完整的，直到它被完全复制，并保证即使服务器被写入失败，它也会持久化。
Kafka使用刻度良好的磁盘结构-无论服务器上有50 KB还是50 TB的持久数据，Kafka都会执行相同的操作。
由于认真对待存储并允许客户端控制其读取位置，可以将Kafka看作是一种专用于高性能、低延迟提交日志存储、复制和传播的专用分布式文件系统。
有关Kafka的提交日志存储和复制设计的详细信息，请阅读此页面。

Kafka for Stream Processing

仅仅读、写和存储数据流是不够的，其目的是支持流的实时处理。
在Kafka中，流处理器是指从输入主题获取连续数据流、对输入执行某些处理并生成连续数据流以输出主题的任何东西。
例如，零售应用程序可能接受销售和发货的输入流，并输出根据这些数据计算的再订单和价格调整流。
可以直接使用生产者和使用者API进行简单处理。然而，对于更复杂的转换，Kafka提供了一个完全集成的StreamsAPI。这允许构建应用程序，这些应用程序可以进行重要的处理，从流中计算聚合或将流连接在一起。
这个工具有助于解决这类应用程序面临的困难问题：处理无序数据，以代码更改的形式重新处理输入，执行有状态的计算等。
Streams API建立在Kafka提供的核心原语之上：它使用生产者和使用者API作为输入，使用Kafka作为有状态存储，并使用相同的组机制在流处理器实例之间进行容错。

Putting the Pieces Together

这种消息传递、存储和流处理的组合似乎不寻常，但对于Kafka作为流媒体平台的角色来说，这是至关重要的。
像HDFS这样的分布式文件系统允许存储用于批处理的静态文件。实际上，这样的系统允许存储和处理过去的历史数据。
传统的企业消息传递系统允许处理订阅后到达的未来消息。以这种方式构建的应用程序将在未来数据到达时处理它。
Kafka将这两种功能结合在一起，这两者的结合对于Kafka作为流媒体应用程序的平台以及流数据管道的使用都是至关重要的。
通过将存储和低延迟订阅相结合，流应用程序可以同样的方式处理过去和未来的数据。也就是说，一个应用程序可以处理历史数据和存储的数据，但是当它到达最后一个记录时，它可以在将来的数据到达时继续处理，而不是结束。这是流处理的一个广义概念，它包括批处理以及消息驱动的应用程序。
同样，对于流数据管道，对实时事件的订阅组合使得可以在非常低延迟的管道中使用Kafka；但是，能够可靠地存储数据的能力使其能够用于必须保证数据传递的关键数据，或者用于与只定期加载数据或可能长时间下降以进行维护的脱机系统的集成。流处理设备可以在数据到达时进行数据转换。
有关保障、API和功能的更多信息，请参见其余文档。