kafka的入门指南和深入探索

kafka是一个分布式的流式平台，它到底是什么意思？

流式平台有以下三个主要的功能：
☆发布和订阅流记录，类似消息队列或企业级的消息系统。
☆你以一种容错的方式存储流记录。
☆当流记录产生时及时处理。

kafka被用于两大类别的应用程序:
☆建立实时的流式数据通道，这个通道能可靠的获取到在系统或应用间的数据
☆建立实时流媒体应用来转换流数据或对流数据做出反应。

为了明白kafka能怎么做这些事情，让我们从下面开始深入探索kafka的功能：
首先看这几个概念：
☆kafka作为集群运行在一个或多个服务器，跨越多个数据中心。
☆kafka集群存储的流记录以主题进行分类。
☆每条记录包含一个键，一个值和一个时间戳。
kafka有四种核心的API:
☆生产者API允许一个应用去发布一个流记录到一个或多个kafka主题上。
☆消费者API允许一个应用去订阅一个或多个主题，并处理流记录。
☆Streams API允许应用作为一个流处理器，消费一个来至于一个或多个主题的输入流；生产一个输出流到一个或多个输出主题，有效地将输入流转换为输出流。
☆Connector API允许构建并运行可重用的生产者或消费者，它们连接kafka主题到已存在的应用或数据系统。例如，关系数据库的连接器(Connector)可以捕获表的每一个变化。

　　kafka客户端和kafka服务器之间的通信是通过一种简单的,高性能的，语言无关的TCP协议完成的。该协议是版本控制的，并保持与旧版本的向后兼容性。我们为kafka提供一个java版本的客户端，其实客户端可以用其他多种语来实现。

主题和日志
    首先深入kafka为流记录提供的核心概念—主题。

    主题就是给发布的记录归类或命名。kafka中的主题总是有多个订阅者。也就是说，一个主题可以有零个、一个或多个消费者去订阅这个主题里面的数据。
    针对每一个主题，kafka集群维护一个像下面这样的分区日志：

    每个分区是一个有序,不变的记录序列，被不断追加到结构化的日志中。分区的记录都分配了一个连续的id号，称为偏移量，偏移量用于唯一标识分区内的每一条记录。

　　kafka集群使用一个可配置的保存期来持久保留所有已发布的记录，不论它们是否已经被消费掉。例如，如果保存策略设置为两天，然后记录发布后的两天内,这个记录可以消费,之后,它将被丢弃来释放空间。不管数据量的大小，kafka都能保持稳定的性能，所以长时间存储数据不是问题。

    事实上，保留在每个消费者基础上的唯一元数据是消费者在日志中的偏移量和位置。偏移量由消费者控制：通常当消费者读取一个记录后会线性的增加偏移量。但实际上，由于位置由消费者控制，消费者可以按任何顺序消费记录。例如，消费者可以重置偏移量以重新处理之前的数据，或者跳至最近的记录并从"now"开始消费。
    这些特性味着kafka消费者们是很灵活的—它们能够加入或者离开而不会影响集群或者其他消费者。例如，你可以使用我们的命令行工具去追踪任何主题的内容，而不影响现有消费者的消费。
    日志中的分区有多种用途。首先，分区允许日志的大小可以超过服务器单机的限制。每个单独的分区必须适合承载它的服务器，但是一个主题可能有很多分区，因此它可以处理任意数量的数据。其次，各个分区是并行单元—更多是为了实现这一点。

分布式
    日志的分区分布在Kafka集群中的服务器上，每个服务器处理数据并请求共享分区。每个分区都通过可配置数量的服务器进行复制以实现容错。
    每个分区都有一个服务器充当“领导者(leader)”，零个或多个服务器充当“追随者(follower)”。leader处理分区所有读写请求，时followers被动的复制这个leader。如果leader出现故障，其中一个follower自动成为新的leader。每个服务器都充当其中一些分区的leader和其分区的follower，因此集群内的负载均衡很好。

地理复制

    Kafka MirrorMaker为您的群集提供地理复制支持。借助MirrorMaker，消息可以跨多个数据中心或云区域进行复制。 您可以在主动/被动场景中将其用于备份和恢复；或者在主动/主动方案中将数据放置得更靠近用户，或者支持数据本地化要求。

生产者
    生产者将数据发布到他们选择的主题。生产者负责选择将哪个记录分配给主题中的哪个分区。这可以以循环方式完成，只是为了均衡负载，或者可以根据某种语义分区功能（例如基于记录中的某个键）完成。

消费者

    消费者用消费组(consumer group)名称标记自己，并且发布到主题的每条记录都被传送到每个订阅消费组中的一个消费者实例。消费者实例可以在单独的进程中或在单独的机器上。
    如果所有消费者实例具有相同的消费组，则记录将有效地在消费者实例上进行负载均衡。
    如果所有消费者实例具有不同的消费组，则每条记录都将广播给所有消费者进程。
　　

    两个服务器Kafka集群托管四个分区（P0-P3）和两个消费组。消费组A有两个消费者实例，而消费组组B有四个消费者实例。
    然而，更常见的是，我们发现主题的消费组很少，每个“逻辑订阅者”都有一个。每个消费组组由许多消费者实例组成，具有可扩展性和容错性。这只不过是发布—订阅语义，其中订阅者是一群消费者而不是一个进程。
    在Kafka中实现消费的方式是将日志中的分区分配给消费者实例，以便每个实例在任何时间点都是“公平分享”分区的独占消费者。维护组中成员的过程是由Kafka协议动态处理的。如果新实例加入该组，则它们将接管来自该组的其他成员的一些分区；如果一个实例死亡，其分区将分配给其余实例。
    Kafka只提供一个分区内记录的总顺序，而不是主题中不同分区之间的顺序。按分区排序与按键分区数据的能力相结合，足以满足大多数应用程序的需求。但是，如果您需要全部记录的总顺序，则可以通过仅有一个分区的主题来实现，但这意味着每个消费组只有一个消费者进程。

多租户

    您可以将Kafka部署为多租户解决方案。通过配置哪些主题可以产生或消费数据来启用多租户。还有配额操作支持。 管理员可以根据请求定义和执行配额以控制客户端使用的代理资源。

保证
kafka的高级API提供以下保证：
☆消息被生产者发送到一个特定的主题分区，消息将以发送的顺序追加到这个分区。比如，如果M1和M2消息都被同一个生产者发送，M1先发送，M1的偏移量将比M2的小且更早出现在日志里。
☆消费者实例按照它们存储在日志中的顺序查看记录。
☆如果一个主题的副本数是N，我们可以容忍N-1个服务器发生故障而不会丢失任何提交到日志中的记录。

关于保证的更多的细节将在文档的设计章节被给出来。

Kafka作为消息系统

    Kafka的流概念如何与传统的企业消息系统相比较？
    消息处理历来有两种模式：队列和发布-订阅。在队列中，消费者池(pool)可以从服务器读取，并且每条记录都会转到其中的一个消费者；在发布-订阅中，记录被广播给所有消费者。这两种模式都有优势和劣势。队列的优势在于它允许您将数据分配到多个消费者处理，从而扩展您的处理。不幸的是，队列不支持多个订阅者—一旦一个进程读取数据，其他进程就不能访问了。发布-订阅允许您将数据广播到多个进程，但无法进行扩展处理，因为每条消息都发送给每个订阅者。
    Kafka的消费组归纳了这两个概念。与队列一样，消费组允许您将处理流程分配到多个进程（消费者组成员）。与发布-订阅一样，Kafka允许您向多个消费组广播消息。
    Kafka模式的优点是每个主题都有这些属性—它可以扩展处理，也可以支持多个订阅者—没有必要再二选一了。
    Kafka也比传统的消息系统有更强大的顺序保证能力。
    传统的队列在服务器上按顺序保存记录，如果多个消费者从队列中消费，则服务器按它们存储的顺序派发记录。但是，尽管服务器按顺序派发记录，但是记录是异步传递给消费者的，它们到达不同的消费者时可能已经乱序了。这实际上意味着在并行消费的情况下记录的顺序会丢失。消息系统通常具有“排他消费者”的概念，只允许一个进程从队列中消耗，但这当然意味没有并行处理能力。
    Kafka做得更好。通过主题内的分区来实现并行，Kafka能够在消费者进程池中提供顺序保证和负载均衡。这是通过将主题中的分区分配给消费组中的消费者来实现的，以便每个分区仅由组中的一个消费者使用。通过这样做，我们确保消费者是该分区的唯一读者，并按顺序使用数据。由于有很多分区，这仍然可以平衡许多消费者实例的负载。但请注意，消费者组中的消费者实例不能多于分区。

Kafka作为存储系统

    任何消息队列都能够解耦消息的生产和消费，还能够有效的存储正在传送的消息。Kafka的不同之处在于它是一个非常好的存储系统。
    Kafka将数据写入磁盘并进行复制以实现容错。Kafka允许生产者等待确认，直到副本复制和持久化全部完成才认为写入成功。
    Kafka使用的磁盘结构很好扩展—无论您在服务器上有50KB还是50TB的持久化数据，Kafka都会执行相同的操作策略。
    由于存储的重要性，并允许客户控制自己的读取位置，您可以将Kafka视为一种专用的分布式文件系统，致力于高性能，低延迟，有保障的日志存储，能够备份和自我复制。
    有关Kafk日志存储和复制设计的详细信息，请阅读本页。

Kafka流处理

    仅读取，写入和存储数据流是不够的，目的是实时处理数据流。
    在Kafka中，流处理器是指从输入主题获取连续数据流，对该输入执行一些处理并生成连续数据流到输出主题。
    例如，零售应用程序可能会接受销售和装运的输入流，并输出一系列重新排序和根据此数据计算出的价格调整。
    可以直接使用生产者API和消费者API进行简单的处理。然而，对于更复杂的转换，Kafka提供了完全集成的Streams API。这允许构建应用程序进行非凡的处理，将计算从流中剥离或加入流一起。
    这个工具有助于解决这类应用程序面临的难题：处理乱序数据，重新处理代码更改的输入，执行有状态的计算等。
    Streams API基于Kafka提供的核心原语构建：它使用生产者API和消费者API输入，使用Kafka进行有状态存储，并在流处理器实例之间使用相同的组机制来实现容错。

把功能结合起来

    消息传递，存储和流处理的这种组合可能看起来很不寻常，但对于Kafka作为流式传输平台的角色来说，这是非常重要的。
    像HDFS这样的分布式文件系统允许存储用于批处理的静态文件。这样的系统允许存储和处理过去的历史数据。
    传统的企业消息系统允许处理订阅后才抵达的消息。以这种方式构建的应用程序处理将来的数据。
    Kafka结合了这两种功能，而且这两种组合对于Kafka用作流式传输应用平台和流式数据管道都非常重要。
    通过将存储和低延迟订阅相结合，流式应用可以以相同的方式处理过去和未来的数据。也就是一个单一的应用程序可以处理历史的，存储的数据，而不是在它达到最后一个记录时结束，它可以在将来的数据到达时继续处理。这是流处理的一般概念，包括批处理以及消息驱动的应用程序。
    同样，对于流式数据管道，结合订阅实时事件，使得可以将Kafka用于非常低延迟的管道；可靠地存储数据的能力可以将其用于必须保证数据交付的关键数据，或者与只能定期加载数据的离线系统集成，或者可能在较长时间内停机进行维护。流处理设施可以在数据到达时进行转换。