kafka简介

简介
Apache Kafka® 是一个分布式流媒体平台。它切确的含义是什么？


我们认为流媒体平台有三个关键功能：


1.它可以让你发布和订阅流记录。在这方面，它类似于一个消息队列或企业消息系统。
2.它允许你以一个容错方式存储流记录。
3.它可以让你在流记录发生时处理它们。

Kafka的优点是什么？

它被两大类应用所使用：

构建实时的流数据管道，实时地在系统之间或应用之间获取数据。
 
构建实时的应用，转换或响应流数据。

为了理解Kafka如何做这些事情，让我们自下而上的深入探究 Kafka的能力。


首先一些概念：

Kafka在一台或多台服务器上作为集群运行。
Kafka集群按分类存储流记录叫作主题。
每条记录由键，值，时间戳组成。

Kafka有4个核心的API：

       生产者API允许一个应用发布一个流记录到一个或多个Kafka主题。

       消费者API允许一个应用订阅一个或多个主题并处理为它们生产的流记录。

      流API允许一个应用像一个流处理器一样工作，从一个或多个主题消费一个输入流并产生一个输出流到一个或多个输出主题，高效地把输入流转换到输出流。

       连接器API允许构建并运行可重用的生产者或消费者，它们连接Kafka主题到已有的应用或数据系统。例如，一个连接到一个关系型数据库的连接器可以捕捉到一张表的每一次变化。


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



主题与日志


让我们首先深入Kafka为流记录提供的核心抽象概念-主题。

        主题是已发布的记录的一个类别或名称。Kafka中的主题常常是多个订阅者；那就是，一个主题可以有0个，1个，或多个消费者订阅到写入到它的数据。

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




每个分区都是记录的有序，不可改变的系列，它持续追加到一个结构化的提交日志。分区中的每个记录都指派了一个系列化标识数字，叫作偏移量，它标明了分区中的每一个记录的惟一性。

Kafka服务器保存着所有发布的消息，不管他们有没有被消费-使用一个可配置的保存期间。例如，如果保存策略被设置为2天，那么在记录发布之后的两天，可以被消费，在这之后它会被丢弃以便释放出空间。Kafka的性能相对于数据大小是高效持久的，所以长时间存储数据不是问题。



事实上，在每个消费者基础上保留的唯一元数据是该日志中该消费者的偏移量或位置。这种偏移由消费者控制：通常消费者在读取记录时会线性地进行偏移，但事实上，由于消费者控制了位置，所以它可以按它喜欢的任何顺序消费记录。例如，一个消费者可以重置为一个旧的偏移量来重新处理以前的数据或是跳到最近的记录并从现在开始消费。

这种特性的结合意味着Kafka的消费者非常轻便-他们可以来去自由，不会对集群和其它消费者有什么大的影响。例如，你可以使用我们的命令行工具去跟踪任何主题的内容，不需要改变任何现有消费者所消耗的内容。



        日志中的分区有多个作用。首先，它允许日志规模超出在单个服务器上的大小。每个独立的分区必须适合承载它的服务器，但一个主题可以有很多个分区，因此它可以处理任意数量的数据。二是他们作为一个平行的单位运行。

分布式


        日志的分区分布在Kafka集群的服务器上，每个服务器处理数据并请求分区共享。每个分区在可配置数量的服务器上是重复的，以便容错。 每个分区有一个服务器作为领导者并有0个或多个服务器作为跟随者。这个领导者为分区处理所有读与写的请求，而追随者被动地复制领导者。如果领导者失败，其中一个跟随者将会自动的成为一个新的领导者。每个服务器充当它的一些分区的领导者和其他人的追随者，因此集群内的负载平衡得很好。

生产者


      生产者发布数据到它们选择的主题上。生产者负责选择分配到主题的哪个分区的哪个记录上。这可以通过循环的方式来完成，只是为了负载均衡，或者可以根据一些语义分区功能（比如记录中的某个键）来完成。

消费者

       消费者为它们自己贴上一个消费者组名，并且在每个订阅消费者组里，发布到一个主题的每个记录被传递到一个消费者实例。消费者实例可以在分散的进程中或是在分散的机器中。

        如果所有的消费者实例有相同的消费者组，那么记录会在消费者实例里有效的被负载均衡。

        如果所有的消费者实例有不同的消费者组，那么每个记录会被广播到所有的消费者进程。





         一个有两台服务器的Kafka集群承载着4个分区（P0-P3）带有两个消费者组。消费者组A有两个消费者实例并且组B有4个。

        然而，更常见的是，我们发现主题有一小部分消费者群，一个用于每个“逻辑订阅者”。为了可扩展性和容错性，每个组由多个消费者实例组成。这仅仅是发布订阅语义，订阅者是消费者集群而不是单个进程。


       Kafka消费方式是通过分割消费者实例上的日志中的分区来实现的，以便在任何时间点，每个实例都是分区中合理份额的相互排斥消费者。保持组中成员资格的进程是由Kafka协议动态处理的。如果新实例加入组，他们将接管组中其他成员的一些分区；如果实例死亡，它的分区将被分配到其余实例中。


       Kafka仅提供了一个分区内记录的总顺序，而不是一个主题的不同分区。每个分区排序加上按键对数据进行分区的能力对于大多数应用程序来说已经足够了。但是如果你要求记录上的一个总排序，你可以爱过一个只有一个分区的主题来获取，但这意味着每个消费者组只有一个消费者进程。

 担保

一个高水平的Kafka给出了以下担保：

  
       由生产者发送到一个特定的主题分区的消息将会按它们被发送的顺序被追加。那么，如果一个记录M1被发送记录M2的同一个生产者发送，并且M1先被发送，那么M1将会有一个比M2更低的偏移量并在日志中出现的更早。

    消费者实例按记录存在日志里的顺序读取。
    对于带有复制因子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的非常低延迟的管道成为可能；但是可靠地存储数据的能力使得用它作为关健数据成为可能。必须保证数据的交付或与仅在周期性地加载数据的脱机系统集成，否则可能会延长维护时间。  流处理工具使数据到达时实现转换成为可能。

 

有任何问题请联系微信 

如果您觉得我的文章给了您帮助，请为我买一杯饮料吧！以下是我的支付宝，意思一下我将非常感激！