发布与订阅 像消息传递系统一样读取和写入数据流。
处理 编写可伸缩的流处理应用程序，这些应用程序可以实时地响应事件。
存储 在分布式的、复制的、容错的集群中安全地存储数据流。
卡夫卡被用来建造实时数据管道和流媒体应用。它是水平可伸缩的，容错的，超快的，并且在成千上万的公司中运行。
我们认为一个流媒体平台有三个关键功能: 它允许您发布和订阅记录流。在这方面，它类似于消息队列或企业消息传递系统。 它允许您以容错的方式存储记录流。 它允许您在发生时处理记录流。
好处是什么? 它被用于两个广泛的应用程序: 构建能够可靠地在系统或应用程序之间获取数据的实时流数据管道 构建对数据流进行转换或响应的实时流应用程序
几个概念: 卡夫卡是在一个或多个服务器上运行的集群。 卡夫卡的集群存储了各种类别的记录，称为主题。 每个记录由一个键、一个值和一个时间戳组成。
卡夫卡有四个核心的api: Producer API ：生产者API允许应用程序将记录流发布到一个或多个卡夫卡主题。 Consumer API ：使用者API允许应用程序订阅一个或多个主题，并处理生成给它们的记录流。 Streams API ：流API允许应用程序充当流处理器，使用来自一个或多个主题的输入流，并生成一个输出流到一个或多个输出主题，有效地将输入流转换为输出流。 The Connector API ：连接器API允许构建和运行可重用的生产者或消费者，将卡夫卡主题与现有的应用程序或数据系统连接起来。例如，连接到关系数据库的连接器可能会捕获到表的每个更改。
在卡夫卡中，客户端和服务器之间的通信是用一个简单的、高性能的、语言无关的TCP协议完成的。该协议是版本控制的，并且与旧版本保持向后兼容。我们为卡夫卡提供了一个Java客户端，但是客户端可以使用多种语言。
Topics and Logs
让我们首先深入了解卡夫卡的核心抽象概念，为主题提供一系列的记录。 主题是记录被发布的一个类别或提要名称。卡夫卡的主题总是多订户;也就是说，一个主题可以有零个、一个或多个订阅所写的数据的消费者。 对于每一个主题，卡夫卡集群都维护一个类似这样的分区日志:
每个分区都是一个有序的、不可变的记录序列，它不断被追加到一个结构化的提交日志中。分区中的记录被分配一个顺序的id号，称为偏移量，它惟一地标识分区中的每个记录。
卡夫卡的集群保留了所有已发布的记录——无论它们是否使用了可配置的保留期。例如，如果保留策略被设置为两天，那么在记录发布后的两天内，它就可以用于消费，之后它将被丢弃以释放空间。卡夫卡的性能在数据大小方面是有效的，因此长期存储数据并不是问题。
实际上，在每个消费者基础上保留的唯一元数据是日志中消费者的偏移量或位置。这个偏移量是由消费者控制的:正常情况下，消费者会在读取记录时线性地提高它的偏移量，但是，事实上，由于该位置是由消费者控制的，它可以按照它喜欢的任何顺序消费记录。例如，用户可以重新设置为旧的偏移量，以重新处理过去的数据，或者跳到最近的记录，并开始从“now”开始消费。
这种特性的组合意味着卡夫卡的消费者非常便宜——他们可以来而不去对集群或其他消费者产生太大的影响。例如，您可以使用我们的命令行工具来“跟踪”任何主题的内容，而不改变任何现有使用者所消耗的内容。
日志中的分区有几个目的。首先，它们允许日志扩展到一个适合于单个服务器的大小。每个单独的分区必须适合承载它的服务器，但是一个主题可能有多个分区，这样它就可以处理任意数量的数据。其次，他们作为并行的单位，在这方面做得更多。
分布
日志的分区分布在卡夫卡集群中的服务器上，每个服务器处理数据和请求共享分区。每个分区都在一个可配置的服务器上进行复制，以供容错。
每个分区都有一个充当“领导者”的服务器，以及充当“追随者”的0或多个服务器。当追随者被动地复制领导者时，领导者处理所有的对分区的读写请求。如果领导失败了，其中的一个追随者就会自动成为新的领导者。每个服务器充当某些分区的领导者，并为其他一些分区提供一个追随者，因此在集群中负载均衡。
生产商
生产者将数据发布到他们所选择的主题上。生产者负责选择将哪个记录分配到该主题中的哪个分区。这可以以循环的方式进行，只是为了平衡负载，或者可以根据一些语义分区功能(根据记录中的一些键)来完成。更多关于分区的使用！
消费者
消费者给自己贴上一个消费者组的标签，每一个发布到一个主题的记录都被交付给每个订阅消费者组中的一个消费者实例。消费者实例可以在单独的进程中，也可以在单独的机器上。
如果所有的消费者实例都有相同的消费者组，那么这些记录将有效地在消费者实例上负载平衡。
如果所有的消费者实例都有不同的消费者组，那么每个记录将被广播到所有的消费者进程。
一个服务器集群主机卡夫卡四分区（求解P0 - P3号）两个消费群体。消费者A组有两个消费者实例，B组有四个。 然而，更常见的是，我们发现主题有一小部分消费者群，一个用于“逻辑订阅者”。每个组由许多可伸缩性和容错性的消费者实例组成。这仅仅是发布订阅语义，订阅者是一个消费者集群而不是单个进程。 在卡夫卡中实现消费的方法是将日志中的分区划分到消费者实例中，这样每个实例在任何时间点都是分区的“公平份额”的独占使用者。保持组中成员资格的过程是由卡夫卡协议动态处理的。如果新实例加入组，他们将接管组中其他成员的一些分区；如果实例死亡，它的分区将被分配到其余实例中。 卡夫卡只在一个分区中提供超过记录的总订单，而不是在一个主题中的不同分区之间。每个分区排序加上按键对数据进行分区的能力对于大多数应用程序来说已经足够了。但是，如果您需要一个完整的订单超过记录，这可以实现只有一个分区的主题，虽然这意味着每个消费者组只有一个消费者进程。
保证 一个高层次的卡夫卡给出了以下担保： 由生产者发送到特定主题分区的消息将按其发送的顺序追加。也就是说，如果一个记录M1是由同一个生产者作为一个记录M2发送，M1是第一个发送，那么M1将有一个较低的偏移量比M2和出现在前面的日志。 消费者实例以它们存储在日志中的顺序查看记录。 对于带有复制因子n的主题，我们将容忍多达n-1个服务器故障，而不会丢失提交给日志的任何记录。 关于这些保证的更多细节在文档的设计部分中给出。
卡夫卡作为消息传递系统 卡夫卡的流概念与传统的企业消息传递系统相比如何？ 传统上，消息传递有两种模式：排队和发布订阅。在队列中，一个用户池可以从服务器读取，每个记录转到其中一个；在发布订阅中，记录被广播给所有消费者。这两种模型各有优点和缺点。排队的优势在于它允许您在多个消费者实例上划分数据处理，这使您可以扩展处理过程。不幸的是，一旦一个进程读取数据，队列就不是多订阅服务器了。发布订阅允许您向多个进程广播数据，但由于每个消息都传递给每个订阅者，所以没有缩放处理的方法。 卡夫卡的消费群体概念概括了这两个概念。与队列一样，消费组允许您对进程集合（消费组成员）进行处理。与发布订阅一样，卡夫卡允许您向多个用户组广播消息。 卡夫卡模型的优点是每一个主题都具有这两个属性，它可以扩展处理，而且是多用户，不需要选择一个或另一个。 卡夫卡比传统的消息传递系统具有更强的排序保证。 传统的队列在服务器上保留记录，如果多个用户从队列中消费，服务器按它们存储的顺序分发记录。然而，虽然服务器按顺序发送记录，但异步地将记录传递给消费者，因此它们可能会在不同的用户上发生故障。这实际上意味着在并行消费的情况下，记录的顺序丢失了。消息传递系统通常通过“只允许一个进程从队列中消费”的概念来解决这个问题，但这当然意味着在处理过程中没有并行性。 卡夫卡做得更好。通过对主题中的并行性概念的划分，卡夫卡能够在一个消费过程池中提供订单保证和负载平衡。这是通过将主题中的分区分配给消费组中的消费者从而使每个分区完全由组中的一个消费者所消耗来实现的。通过这样做，我们确保消费者是该分区的唯一读者，并按顺序消费数据。由于有许多分区，所以仍然在许多消费者实例之间平衡负载。但是请注意，消费者组中的消费者实例不能多于分区。
卡夫卡作为存储系统 任何消息队列，允许发布消息，不需要消耗它们，有效地充当了飞行消息的存储系统。卡夫卡的不同之处在于它是一个非常好的存储系统。 写入卡夫卡的数据被写入磁盘并被复制用于容错。卡夫卡允许生产者等待确认，这样在完全复制并保证即使服务器写入失败时也不会被认为是完整的。 卡夫卡使用卡夫卡的磁盘结构，无论服务器上有50 KB还是50 TB的持久数据，都将执行相同的操作。 由于认真对待存储并允许客户控制读位置，您可以把卡夫卡看作一种专门用于高性能、低延迟提交日志存储、复制和传播的分布式文件系统。 有关卡夫卡提交日志存储和复制设计的详细信息，请阅读此页。
流处理卡夫卡 仅仅读取、写入和存储数据流是不够的，其目的是使流的实时处理成为可能。 在卡夫卡中，流处理器是从输入主题获取连续数据流的任何东西，对该输入执行一些处理，并将连续的数据流输出到输出主题。 例如，一个零售的应用可能需要在销售和出货量的输入流，输出流的重新排序和价格调整计算了这个数据。 使用生产者和消费者API直接进行简单处理是可能的。然而，对于更复杂的转换，卡夫卡提供了一个完全集成的流API。这允许构建不进行琐碎处理的应用程序，计算流的聚合或连接流。 这个工具有助于解决这类应用程序面临的难题：处理非顺序数据、代码更改后的输入、执行状态计算等。 流API基于卡夫卡提供的核心原语：它使用生产者和消费者API进行输入，使用卡夫卡进行状态存储，并在流处理器实例中使用同一组机制进行容错。
把碎片拼在一起 这种消息传递、存储和流处理的组合可能看起来不寻常，但对卡夫卡作为流媒体平台的角色至关重要。 分布式文件系统HDFS存储像允许批处理静态文件。实际上，这样的系统允许从过去存储和处理历史数据。 传统的企业消息系统允许处理订阅后到达的未来消息。以这种方式构建的应用程序处理将来的数据。 卡夫卡将这两种功能结合在一起，对于卡夫卡作为流应用程序的平台以及流数据管道的使用来说，两者的结合是至关重要的。 通过结合存储和低延迟订阅，流式应用程序可以以同样的方式处理过去和未来的数据。也就是说，一个应用程序可以处理历史的、存储的数据，而不是当它到达最后一个记录时结束，它可以在将来的数据到来时继续处理。这是流处理，包括批处理以及消息驱动的应用程序的一个广义的概念。 同样的数据流管道订阅实时事件的结合使得卡夫卡的使用非常低延迟的管道；但能够存储数据可靠，可以使用它的关键数据，必须保证数据传送或脱机系统负荷数据定期或可能走的维修时间较长的整合。流处理设备使数据在到达时转换成为可能。 有关卡夫卡提供的保证、api和功能的更多信息，请参见文档的其余部分。
快速入门
使用场景
报文发送 网站活动跟踪
