kafka官方文档翻译-introduction

kafka被用来创建实时数据通道和流应用。它可以水平扩展，可以容错，处理速度非常快（wicked fast），并且运行在成千上万公司的生产环境中。

kafka是一个分布式流平台。确切含义是什么？

我们认为一个流平台具有3个关键能力：

     1.它允许您发布和订阅记录流。在这方面，它类似于消息队列或企业消息传递系统

     2.它允许您以容错的方式存储记录流

     3.它可以实时处理记录流。

kafka的好处是什么？

它被应用于两个广泛的应用类型：

     1.构建能够可靠地在系统或应用程序之间获取数据的实时流数据管道  

     2.构建对数据流进行转换或响应的实时流应用程序

为了理解kafka是如何做这些事情的，让我们从底层开始探索kafka的能力。

一些基本概念:

     1.kafka在一台服务器或多台服务器上以集群的方式运行。

     2.kafka的集群存储了各种类别的记录，这些类别称为主题。

     3.每条记录由一个键、一个值和一个时间戳组成。

kafka有四类核心api：

    1.生产者API允许应用程序将记录流发布到一个或多个kafka主题。

    2.消费者API允许应用程序订阅一个或多个主题，并处理生成给它们的记录流。

    3.Streams API允许应用程序充当流处理器，消费来自一个或多个主题的输入流，并将输出流输出到一个或多个输出主题，从而有效地将输入流转换为输出流。

    4.连接器API允许构建和运行可重用的生产者或消费者，将Kafka主题连接到现有的应用程序或数据系统。例如，关系数据库的连接器可能捕获到表的每一个更改。

在Kafka中，客户端和服务器之间的通信是用一个简单的、高性能的、语言无关的TCP协议完成的。该协议是版本化的，并与旧版本保持向后兼容。我们为Kafka提供一个Java客户端，但是客户端可以使用多种语言。

Topics and Logs

让我们首先深入了解核心抽象，kafka提供给一个记录流——主题。

主题是发布记录的类别或提要名称。kafka的主题总是多订阅者的；也就是说，一个主题可以有零个、一个或多个订阅了写入数据的消费者。

对于每个主题，Kafka集群维护一个分区日志，它看起来像这样:

每个分区都是一个有序的、不可变的记录序列，记录不断被附加到结构化的提交日志中。分区中的记录都分配了一个名为偏移量的连续id号，它唯一地标识分区中的每个记录。

通过设置保留时间，kafka集群保留了所有已发布的记录——无论它们是否消费了。例如，如果保留策略设置为两天，那么在记录发布之后的两天内，它就可以用于消费，之后将被丢弃以释放空间。kafka的性能在数据大小上是有效的常数，所以长期存储数据并不是问题。

实际上，在每个消费者基础上保留的唯一元数据是该用户在日志中的偏移量或位置。这个偏移量由使用者控制:通常情况下，消费者会随着读取记录而线性增加偏移量，但实际上，由于该位置是由消费者控制的，它可以按照它喜欢的任意顺序消耗记录。例如，消费者可以重新设置旧的偏移量来重新处理过去的数据，或者跳到最近的记录，并从“现在”开始消费。

这种特性的组合意味着kafka的消费者非常便宜——他们可以在不影响集群或其他消费者的情况下来来去去。例如，您可以使用我们的命令行工具来“跟踪”任何主题的内容，而不改变任何现有消费者所消费的内容。

日志中的分区有多种用途。首先，它们允许日志的规模超出适用于单个服务器的大小。每个单独的分区必须适合承载它的服务器，但是一个主题可能有多个分区，因此它可以处理任意数量的数据。其次，它们作为并行的单元。

Distribution

日志的分区分布在Kafka集群中的服务器上，每个服务器处理数据，并请求共享分区。每个分区被复制到多个服务器上（服务器数量可以配置），用于容错。

每个分区都有一个服务器充当“领导者”，0或更多的服务器充当“追随者”。当追随者被动地复制领导者时，领导者处理所有对分区的读和写请求。如果领导者失败，其中一个追随者将自动成为新的领导者。每个服务器作为它的某些分区的领导者，以及其他一些分区的跟随者，因此负载在集群中是均衡的。

Producers

生产者将数据发布到他们选择的主题上。生产者负责选择将哪个记录分配到该主题中的哪个分区。这可以用一个循环的方式来完成，仅仅是为了平衡负载，或者可以根据一些语义分区函数来完成(比方说根据记录中的一些关键字)。

Consumers

消费者给自己贴上一个消费者组的标签，每一个发布到一个主题的记录都被交付给每个订阅消费者组中的一个消费者实例。消费者实例可以在单独的进程中，也可以在单独的机器上。

如果所有的消费者实例属于相同的消费组，那么记录将有效地负载到每个消费者实例上。

如果所有的消费者实例属于不同的消费组，那么每个记录将被广播到所有的消费者进行处理。

一个两个服务器Kafka集群，承载4个分区(p0 - p3)和两个消费者组。消费者组A有两个消费者实例，B组有4个。

然而，更常见的是，我们发现主题有少量的用户组，每个“逻辑订阅者”都有一个。每个组都由许多用于可伸缩性和容错的消费者实例组成。这只不过是发布-订阅语义，订阅者是一组消费者，而不是单个进程。

在Kafka中实现消费的方式是将日志中的分区划分为消费者实例，以便每个实例都是在任何时间点上“公平共享”分区的唯一使用者。这一维护团队成员的过程是由Kafka协议动态处理的。如果新实例加入该小组，他们将接管该小组其他成员的一些分区;如果一个实例死亡，它的分区将被分配给其余的实例。

Kafka只提供一个分区内的记录的总顺序，而不是主题中的不同分区之间的总顺序。 每分区排序 + 按key分配数据的能力足以满足大多数应用。 但是，如果您需要记录的总顺序，可以使用仅具有一个分区的主题来实现，尽管这意味着每个消费者组只有一个消费者进程。

Guarantees

Kafka给出了以下保证：

• 由一个生产者发送给指定主题分区的消息将按发送的顺序追加。也就是说，如果记录M1和M2被同一个生产者发送，并且M1被先发送，那么M1将会有一个比M2更低的偏移量，并在日志的前面出现。
• 一个消费者实例按照存储在日志中的顺序看到记录。
• 对于一个带有复制因子N的主题，我们将容忍高达N - 1个服务器故障，而不会丢失任何提交到日志的记录

关于这些保证的更多细节在文档的设计部分给出。

Kafka as a Messaging System

与传统的企业消息传递系统相比，Kafka的信息流是怎样的呢?

消息传递传统上有两种模式:排队和发布订阅。在一个队列中，一个消费者池可以从一个服务器上读取数据，并且每个记录被池子中的一个消费者消费;在发布-订阅中，记录向所有消费者广播。这两种模型都有优点和缺点。排队的优势在于，它允许您在多个消费者实例上平摊数据处理，这可以让您对处理进行扩展。不幸的是，队列不是多订阅的——一旦一个进程消费了一条数据，这条数据就消失了。发布-订阅允许将数据广播到多个进程，但一旦每个消息都传递给每个订阅服务器，就无法扩展处理。

Kafka的消费者群体概念概括了这两个概念。与队列一样，消费者组允许您在一个进程集合(消费者组的成员)中分配处理。与发布订阅一样，Kafka允许您向多个消费群体广播消息。

Kafka模型的优点是，每个主题都有这些属性——它既可以扩展，也可以多订阅——不需要两者只能选其一。

与传统的消息传递系统相比，Kafka有更强的顺序保证。

传统的队列按顺序在服务器上保留记录，如果多个使用者从队列中消费，则服务器会按存储的顺序分发记录。然而，尽管服务器会按顺序分发记录，但这些记录是异步传递给消费者的，所以它们可能会在不同的消费者中出现。这实际上意味着在并行消费的情况下，记录的顺序就乱了。消息传递系统通常使用“独占消费者”的概念来解决这个问题，它只允许一个进程从队列中消费，但这当然意味着在处理过程中没有并行性。

Kafka做得更好。通过在主题中有一个并行概念-partition，Kafka能够同时提供顺序保证和负载均衡。这是通过将主题中的分区分配给消费者组中的消费者来实现的，以致于每个分区恰好被组中的一个消费者所消费。通过这样做，确保消费者是该分区的唯一阅读者，并按顺序消费数据。一旦有多个分区，就可以在多个消费者实例上实现负载均很。但是请注意，组中的消费者不能多于分区。

Kafka as Storage System

任何允许发布消息与使用它们分离的消息队列都可以有效地充当飞行消息的存储系统。Kafka的不同之处在于它是一个很好的存储系统。

写入Kafka的数据被写入磁盘，并被复制用于容错。kafka允许生产者等待确认，以便在完全复制并保证即使服务器写入失败时，写入也不完整。

Kafka磁盘结构的扩展性很好，无论您在服务器上有50 KB还是50 TB的持久数据，Kafka都将执行相同的操作。

由于认真对待存储并允许客户控制其读取位置，您可以将Kafka看作是一种专用于高性能、低延迟提交日志存储、复制和传播的分布式文件系统。

有关Kafka的提交日志存储和复制设计的详细信息，请阅读此页。

Kafka for Streaming Processing

仅仅读取、写入和存储数据流是不够的，其目的是实现流的实时处理。

在Kafka中，流处理器从输入topic获取持续的数据流，然后处理数据流，最后向输出topic持续输出数据流。

例如，零售应用程序可能接收销售和发货的输入流，并输出一个价格调整记录流。

可以使用生产者和消费者api直接进行简单的处理。然而，对于更复杂的转换，Kafka提供了一个完全集成的流API。这使得构建应用程序可以进行非平凡的处理，这些处理计算流聚合或将流连接到一起。

这个工具帮助解决了这种类型的应用程序所面临的难题:处理无序数据、当代码更改重新处理输入、执行有状态的计算等。

Streams API基于Kafka提供的核心原语:它使用生产者和消费者API作为输入，使用Kafka进行有状态的存储，并在流处理器实例中使用相同的组机制来进行容错。

Putting the Pieces Together

这种消息传递、存储和流处理的组合看起来很不寻常，但对于Kafka作为流平台的角色来说，这是必不可少的。

像HDFS这样的分布式文件系统允许为批处理存储静态文件。实际上，这样的系统允许存储和处理过去的历史数据。

传统的企业消息传递系统允许处理在订阅后到达的未来消息。以这种方式构建的应用程序在到达时处理未来的数据。

Kafka结合了这两种功能，这两者的结合对于Kafka的使用来说是一个重要的平台，可以作为流应用程序的平台，也可以用于流数据管道。

通过组合存储和低延迟订阅，流媒体应用程序可以以同样的方式处理过去和将来的数据。这是一个单一的应用程序可以处理历史的、存储的数据，而不是在它到达最后一个记录时结束，它可以在未来的数据到达时继续处理。这是一个关于流处理的通用概念，这个概念包含了批处理和消息驱动的应用程序。

同样，对于流媒体数据管道，订阅和实时事件的结合使得使用Kafka用于非常低延迟的管道成为可能;但是，能够可靠地存储数据的能力使其能够用于关键数据，在这些关键数据中，必须保证数据的交付，或者是与离线系统集成，这些系统只能周期性地加载数据，或者可以进行更长时间的维护。流处理设施可以在数据到达时转换数据。

有关保证、api和性能的更多信息，Kafka提供了其他文档。