Kafka基本概述

Kafka功能简述

1. 发布、订阅模式：类似于消息队列，用于数据流的读写。
2. 数据处理：支持编写可实时处理事件的可扩展流处理应用程序。
3. 存储：将流式数据以一种分布式，可备份，支持单点故障的安全的保存在分布式系统中。

总结：Kafka可以用于构建实时数据管道传输和流式应用程序。它具有水平可伸缩性、容错性、运行速度极快，并在数千家公司中投入生产。

Kafka流处理平台

流处理平台的三个核心功能如下：

1. 发布和订阅数据流中的记录。（类似于消息队列）
2. 以可容错的方式持久化保存数据流。
3. 处理数据流中的数据。

Kafka的典型应用场景包括如下：

1. 构建在系统或应用程序之间需要可靠地获取数据的实时流数据管道（应用之间传递数据）
2. 构建转换或处理数据流的实时流应用程序（实时处理流式数据）

为了详细的了解Kafka是如何实现这些内容的，我们需要来依次学习一些Kafka对应的能力。

首先，我们需要接受如下核心概念：

1. Kafka作为一个集群在一个或多个服务器上运行，这些服务器可以跨越多个数据中心。
2. Kafka集群将数据流存储在称为主题的Topic中。
3. 每条记录由一个键、一个值和一个时间戳组成。

Kafka提供了如下四类API：

1. Producer API用于应用程序发布流式数据至1个或多个Topic中。
2. Consumer API用于应用程序订阅1个或多个Topic中流式数据并处理它们。
3. Streams API允许应用程序充当流处理器，从一个或多个主题接收输入数据流，并输出到一个或多个输出主题的输出流中，有效地将输入流转换为输出流。
4. Connector API允许构建和运行将Kafka主题连接到现有应用程序或数据系统的可复用的生产者或消费者。例如，到关系数据库的连接器可能捕获每个对数据库表的修改。

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

主题与日志（数据记录）

主题是数据记录发布的类别或名称。
Kafka中的一个主题可以有零个、一个或多个订阅者。

对于每个主题，Kafka集群维护一个分区日志，如下所示：

每个分区都是一个有序的、不可变的记录序列，这些记录连续地附加到一个结构化的提交日志中。每个分区中的记录都被分配一个称为偏移量的序列ID号，该序列ID号唯一地标识分区内的每个记录。

Kafka集群使用一个可配置的保留期持久地保存所有已发布的记录——不管它们是否已经被消耗。例如，如果保留策略被设置为两天，那么对于记录发布后的两天，它可用于消费，之后它将被丢弃以释放空间。Kafka的性能相对于数据大小实际上是恒定的，因此长时间存储数据不成问题。

事实上，基于每个使用者保留的唯一元数据是该使用者在日志中的偏移量或位置。这种偏移由消费者控制：通常消费者在读取记录时线性地提前其偏移量，但实际上，由于位置由消费者控制，因此它可以以任意顺序消费记录。例如，消费者可以重置为旧的偏移量来重新处理过去的数据，或者跳到最近的记录，并从“现在”开始消费。

这些特性的组合意味着Kafka消费者非常轻量——他们来来往往对集群或其他消费者没有太大影响。例如，您可以使用我们的命令行工具“跟踪”任何主题的内容，而不必更改任何现有消费者所消费的内容。

日志中的分区有多种用途。首先，它们允许日志扩展到超过适合单个服务器的大小。每个单独的分区必须适合于托管它的服务器，但是一个主题可能有许多分区，因此它可以处理任意数量的数据。其次，它们在不同的分区中是并行的。

分布

日志的分区分布在Kafka集群中的服务器上，每个服务器在处理数据和请求时共享分区。为了容错，每个分区在可配置数量的服务器上进行备份。

每个分区都有一个Leader的服务器和零个或多个充当followers的服务器。Leader处理分区的所有读写请求，而followers被动地复制领导者。如果Leader失败，一个follower将自动成为新的Leader。每个服务器充当其某些分区的Leader和其他分区的follower，因此负载在集群中得到很好的平衡。

Ps：服务器和分区的关系通常是多对多的。follower平时的工作仅仅是备份，只有当Leader挂了后才会处理读写请求。

跨地域备份

Kafka MirrorMaker为您的集群提供地理复制支持。
使用MirrorMaker，消息跨多个数据中心或云区域进行复制。
您可以在主动/被动场景中使用此选项进行备份和恢复；或者在主动/主动场景中使用此选项来将数据放置得更靠近用户，或者支持数据局部性需求。

生产者

生产者负责将数据发布到他们选择的主题中。
生产者负责选择将哪条数据分配给哪个主题中的哪个分区。
在选择分区时可以以循环方式完成，这样有助于平衡负载。或者可以根据一些语义分区函数（比如基于记录中的某个键）来完成。

消费者

消费者用消费者组名称标记自己，发布到主题的每条数据记录被传递到每个订阅的消费者组中的其中一个消费者实例。消费者实例可以在单独的进程中或在单独的机器上。
如果所有消费者实例属于相同的消费者组，则数据记录将在消费者实例上进行有效的负载平衡。
如果所有消费者实例具有不同的消费者组，则每个记录将被广播到所有消费者进程。

Ps：通过消费者和消费者组的关系从而实现了负载均衡和广播等方式的平衡。

Kafka只对分区内的记录提供顺序一致性的保证，而不能保证在不同主题的不同分区之间确保总顺序的一致性。
对大多数应用程序来说，按分区排序结合按键分区数据的能力就足够了。
但是，如果需要保证全局顺序，那么可以使用只有一个分区的Topic来实现，但是这将意味着每个消费者组只有一个消费者进程。

多租户

kafka本身支持了多租户的解决方案。
通过配置哪些主题可以生成或使用数据来启用多租户。
同时Kafka也支持配额的操作。管理员可以定义和执行请求的配额，以控制客户端使用的代理资源。

Guarantees特性

Kafka在高一致性的级别下，可以保证如下内容：

1. 生产者发送到特定主题分区的消息将按照它们发送的顺序被消费。也就是说，如果记录M1由与记录M2相同的生产者发送，并且首先发送M1，那么M1将具有比M2更低的偏移量，并且出现在日志中的更早。
2. 一个消费者实例以记录存储在日志中的顺序读取记录。
3. 对于具有复制因子N的主题，我们将在不丢失提交到日志的任何记录的情况下容忍多达N-1服务器故障。

作为消息队列的Kafka

与传统的消息队列系统相比，Kafka有什么特点呢？

传统的消息队列有两种模式：队列和发布订阅。
在队列中，消费者们可以从服务器读取记录，并且每个记录都分配给其中一个消费者；
在发布-订阅中，该记录被广播到所有消费者。
这两种模式各有其优点和缺点：
队列的优势在于，它允许您在多个使用者实例上共享数据处理，从而可以扩展处理。缺点在于，队列不是多订阅者，即一旦一个进程读取了某条数据，则该数据已经消失，无法发送给其他的消费者。
发布-订阅允许将数据广播到多个进程，但是由于每个消息都发送到每个订阅者，因此无法扩展处理。

Kafka的消费组概念整合了这两个概念。
与队列一样，使用者组允许您将处理划分为一组进程（使用者组的成员）。与发布-订阅一样，Kafka允许您向多个消费者组广播消息。
Kafka模型的优点是，每个主题都具有这些属性——它可以扩展处理，而且是多用户处理。

此外，Kafka比传统的消息传递系统具有更强的排序保证。
传统队列在服务器上按顺序保留记录，如果多个消费者从队列中消费，则服务器按照记录的存储顺序分发记录。然而，尽管服务器按顺序分发记录，但是记录是异步地传递给使用者的，因此它们可能按顺序到达不同的使用者。这实际上意味着在存在并行消耗的情况下会丢失记录的排序。消息传递系统通常通过具有“独占消费者”的概念来解决这个问题，该概念只允许一个进程从队列中消费，但这当然意味着在处理中没有并行性。

Kafka做得更好。通过具有主题中的并行性（分区）的概念，Kafka能够在消费者池上提供排序保证和负载平衡。这是通过将主题中的分区分配给使用者组中的使用者来实现的，以便每个分区都恰好被组中的一个使用者所使用。通过这样做，我们确保使用者是该分区的唯一读取者，并按顺序使用数据。由于存在许多分区，这仍然在许多使用者实例上平衡负载。但是，请注意，消费者组中的消费者实例数不能超过分区数。

作为存储系统的Kafka

任何允许发布消息与消费消息解耦的消息队列实际上都充当了尚未结束消息的存储系统。
Kafka的不同之处在于它是一个更加优秀、完善的存储系统。

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

Kafka使用的磁盘结构——无论服务器上有50KB或50TB的持久数据，Kafka都将执行相同的操作。

由于特殊处理存储并允许客户机控制其读取位置，因此可以将Kafka看作一种专用的分布式文件系统，专门用于高性能、低延迟的提交日志存储、复制和传播。

作为流处理系统的Kafka

仅仅读取、写入和存储数据流是不够的，其利用消息队列的最终目的是实现流数据的实时处理。

在Kafka中，流处理器是指从输入主题获取连续的数据流，对该输入执行一些处理，并生成连续的数据流以输出到主题。

例如，零售应用程序可以接收销售和发货的输入流，并输出根据该数据计算的重新排序和价格调整流。

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

这个工具有助于解决此类应用程序面临的难题：处理无序数据、在代码更改时重新处理输入、执行有状态计算等。

流处理API建立在Kafka提供的核心功能之上：它使用生产者和消费者API进行输入，使用Kafka进行有状态存储，并且在流处理器实例之间使用相同的组机制进行容错。

组合起来

消息传递、存储和流处理的这种组合对于Kafka作为流平台的角色来说，这是至关重要的。

像HDFS这样的分布式文件系统允许存储静态文件以进行批处理。这样的系统有效地允许存储和处理来自过去的历史数据。

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

Kafka结合了这两种能力，并且这种组合对于Kafka作为流式应用程序以及流式数据管道的平台的使用都是至关重要的。

通过结合存储和低延迟订阅，流应用程序可以以相同的方式处理过去和未来的数据。也就是说，单个应用程序可以处理历史存储的数据，但是当到达最后一条记录时，它不会结束，而是可以在将来数据到达时继续处理。这是包含批处理和消息驱动应用程序的流处理的一般概念。

同样地，对于流式数据流水线，对实时事件的订阅的组合使得能够将Kafka用于非常低延迟的流水线；但是能够可靠地存储数据使得能够将其用于必须保证数据传输的关键数据或用于集成。流处理设备使得可以在数据到达时对其进行转换。