1. 介绍

Kafka 是一种高吞吐量的分布式发布订阅消息系统, 官方定义这个流处理平台应该具备如下能力:

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

2)它允许您以容错方式存储记录流。

3)它允许您在记录发生时处理它。

Kafka 有什么好处?

它被用于两大类别的应用程序:

1)构建实时的流式数据管道,这个管道能使系统和应用程序之间实时获取数据

2)构建转换或响应实时流数据的应用程序

要了解Kafka如何做这些事情,让我们从下而上地探索和探索Kafka的能力。

Kafka的一些概念

  • Kafka 运行在一个或多个节点组成的集群之上
  • Kafka 存储的数据流以topics的形式进行分类
  • 每一表record 包含一个KEY,一个VALUE,一个timestamp

Kafka 有4套核心API:

  • Producer API 允许应用程序将流记录发布到一个或多个Kafka主题。
  • Consumer API 允许应用程序订阅一个或多个主题,并处理为其生成的记录流。
  • Streams API 允许应用程序充当流处理器,处理来自一个或多个主题的输入流并产生到一个或多个输出主题的输出流,有效地将输入流转换为输出流。
  • Connector API 允许构建和运行可重用的生产者或消费者,将Kafka主题连接到现有应用程序或数据系统。 例如,关系数据库的连接器可能捕获对表的每个更改。

kafka-apis

在Kafka中,客户端和服务器之间的通信使用简单的高性能语言无关的TCP协议来完成。 此协议版本化,并保持与旧版本的向后兼容性。 Kafka本身提供了Java客户端,同时也提供了多语言支持。

Topics and Logs

让我们首先深入Kafka提供的流式记录的核心抽象 – Topic。

Topic 是发布的记录类别或Feed名称。Topic在Kafka总是多用户; 也就是说,主题可以具有零个,一个或多个订阅其的数据的消费者。

每一个Topic, 都会维护一个分区(partition )日志,如下图:

1

每个分区都是有序的,不可变的记录序列,不断地增加到结构化提交日志。 分区中的每条记录都有一个称为offset的顺序ID号,它唯一地标识分区内的每条记录。

Kafka集群保留所有已发布的记录,无论它们是否被消费(可以配置保留时间)。 例如,如果保留策略设置为两天,那么记录将保留两天,之后将被丢弃以释放空间。 Kafka的性能在传输数据的大小,所以长时间存储数据不是问题。

1

 

事实上,每个消费者保存的元数据是日志中的offset位置。offset由消费者控制:通常消费者在读取记录时线性地提前其偏移,但是实际上,由于位置由消费者控制,它可以按照喜欢的任何顺序来消费记录。例如,消费者可以重置到较旧的偏移以重新处理来自过去的数据或者跳到最近的记录并开始从“现在”消费。

这些功能的组合意味着Kafka消费者非常便宜 – 他们可以来来去去,对群集或其他消费者没有太大的影响。例如,您可以使用我们的命令行工具“拖动”任何主题的内容,而无需更改任何现有用户使用的内容。

日志中的分区有几个目的。首先,它们允许日志扩展到适合单个服务器的大小。每个单独的分区必须适合托管它的服务器,但一个主题可能有许多分区,因此它可以处理任意数量的数据。第二,它们作为并行性的单位

Distribution

日志的partition分布在Kafka集群中的节点上。 每个分区都会有多个复本(可配置数量),以实现容错。

每个分区都有用作“leader”的一个服务器和充当“followers”的零个或多个服务器。 leader处理分区的所有读取和写入请求,而follower被动地复制领导者。 如果leader失败,其中一个follower将自动成为新的leader。 每个节点会是其中一些分区的leader或其他分区的follower,所以负载在集群内是平衡的。

Producers

生产者将数据发布到他们选择的主题。 同时负责选择哪个记录分配给主题内的哪个分区。 这可以以循环方式完成以简单地平衡负载,或者它可以根据一些语义分区函数(例如基于记录中的一些密钥)来完成。

Consumers

消费者使用consumer group 标记自己,每个订阅consumer group中的每个消费者实例(订阅了的消费都)都能从Topic中获得订阅的记录。 消费者实例可以运行在单独的进程中或也可以在单独的机器上。

如果所有消费者实例具有相同的消费者组,则记录将有效地在消费者实例上进行负载平衡。

如果所有消费者实例具有不同的消费者组,则每个记录将被广播到所有消费者进程。

consumer-groups

上图中是两个服务器组成的Kafka集群,它们托管四个分区(P0-P3)与两个消费者组。消费者组A有两个消费者实例,组B有四个。

通常,我们发现主题具有少量的消费者组,每个“逻辑用户”一个。每个组由用于可伸缩性和容错的许多消费者实例组成。这只是发布 – 订阅语义,其中订户是消费者的集群而不是单个进程。

在Kafka中实现的方式是通过划分消费者实例上的日志中的分区,使得每个实例在任何时间点是分区的“公平共享”的独占消费者。维护组中成员资格的过程由Kafka协议动态处理。如果新实例加入组,则它们将从组的其他成员接管一些分区;如果实例死机,其分区将分发到其余实例。

Kafka只提供一个分区内的记录的总顺序,而不是主题中的不同分区之间。每个分区按键排序,这种模式对对于大多数应用程序是足够的。但是,如果您需要对记录进行总排序,则可以使用只有一个分区的主题来实现,但这将意味着每个用户组只有一个使用者进程。

Guarantees

Kafka提供以下保证:

  • 生产者发送到特定主题分区的消息将按照它们发送的顺序增加到分区中。 也就是说,如果记录M1与记录M2由相同的生成器发送,并且M1首先被发送,则M1将具有比M2更低的偏移并且在日志中较早出现。
  • 消费者实例按存储在日志中的顺序查看记录。
  • 对于具有复制因子N的Topic,我们将允许最多N-1个服务器故障,而不会丢失提交到日志的任何记录。

Kafka 是一个消息系统

Kafka的流概念与传统的企业消息系统相比如何?

消息传统上有两种模式:队列和发布订阅。在队列中,消费者可以从服务器读取每个记录并且每个记录取一次;在发布 – 订阅中,记录被广播给所有消费者。这两种模式都有其优点和缺点。队列的优势在于它允许多个消费者实例对数据处理,可以使用处理规模化。不幸的是,队列不是多用户 – 一旦一个进程读取已经消失的数据就会失败。发布订阅允许您将数据广播传送到多个进程,但是没有办法缩放处理,因为每个消息都发送给每个订阅者。

Kafka中的consumer group 概括了这两个概念。与队列一样,使用者组允许您对一组进程(由消费者组成)分配处理。同样发布 – 订阅模式下,Kafka允许您向多个用户组广播消息。

Kafka的模型的优点是每个主题都有这些属性 – 它可以扩展处理,也是多订户 – 没有必要选择一个或另一个。

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

传统队列在服务器上按顺序保留记录,并且如果多个消费者从队列中消耗,则服务器按照它们被存储的顺序发出记录。然而,尽管服务器按顺序发出记录,但是记录被异步地递送给消费者,因此他们可能在不同的消费者处乱序到达。这意味着在并行消耗的情况下记录的顺序性无法保证。消息传递系统一般会通过只配置一个进程处理“独占消费者”的概念来解决这个问题,但是当然这意味着在处理中没有并行性。

Kafka做得更好。通过在主题内部具有并行性的概念 (分区) ,Kafka能够为消费者进程池提供排序保证和负载均衡。可以通过将主题中的分区分配给消费者组中的消费者来实现,使得每个分区仅由组中的一个消费者消费。通过这样做,我们可以确保消费者是该分区的唯一读取器,并按顺序消耗数据。由于有许多分区,通常可以保证负载均衡。但请注意,消费者组中消费者实例不能比分区多。

Kafka 是一个存储系统

任何消息队列都允许发布消息。 Kafka的不同之处在于它是一个非常好的存储系统。

写入到Kafka中的数据会写入磁盘并复制以用于容错。 Kafka允许生产者等待确认直到它被完全复制,保证写入的数据是完整的。可以将Kafka视为一种专用于高性能,低延迟的日志存储,复制和传播的特殊用途分布式文件系统。

Kafka 流式处理

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

在Kafka中,流处理器是从输入主题获取连续数据流,对这个输入执行一些处理,并产生连续数据流输出到Topic。

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

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

这个工具帮助解决:处理乱序数据,代码处理后再输入,执行状态计算等。

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

Putting the Pieces Together

这种消息传递,存储和流处理的组合可能看起来不寻常,但它对于Kafka作为流媒体平台的作用至关重要。

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

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

Kafka结合了这两个功能,这种组合对于Kafka作为流应用程序和流数据流水线的平台至关重要。

通过组合存储和低延迟订阅,流应用程序可以以相同的方式处理过去和未来的数据。这是一个单一的应用程序可以处理历史数据,已经存储的数据,而不是结束时,当它到达最后一个记录,它可以保持处理作为未来的数据到达。这是包含批处理以及消息驱动应用程序的流处理的概括概念。

同样,对于流式处理,订阅实时事件的组合使得可以将Kafka用于低延迟的流水线处理; 可靠地存储数据能力可以将它用于必须保证数据被传到另一端的处理,或者用于与仅定期加载数据或者可以长时间进行维护的离线系统集成。流

 

 

小结:

本文主要对官方的文档进行了一些翻译学习,由于水平有限有些地方翻译的可能不对,同时由于接触时间不长有些地方可能理解不太准确。

 

欢迎大家批评指证

 

参考:http://kafka.apache.org/documentation.html