卡夫卡是一个分布式的流媒体平台##
流媒体平台有三个关键的功能:
-
发布和订阅记录流，类似于消息队列或企业消息传递系统。
-
以容错和持久的方式存储记录流
-
处理出现的记录流
Kafaka通常应用于两大类应用:
-
构建可以在系统或者应用程序之间可靠获取数据的实时数据流管道
-
构建实时流应用程序，用于转换或响应数据流
要了解卡夫卡如何做这些事情，让我们深入探索卡夫卡的能力:
首先明确几个概念:
-
Kafka作为一个集群运行在一台或多台可以跨越多个数据中心的服务器上。
-
卡夫卡集群在称为主题的类别中存储记录流。
-
每条记录由一个键，一个值和一个时间戳组成。
Kafka有四个核心的API:
-
Producer API允许应用程序将记录流发布到一个或多个Kafka主题。
-
Consumer API允许应用程序订阅一个或多个主题并处理为他们生成的记录流。
-
Streams API允许应用程序充当流处理器，从一个或多个主题中消耗输入流，并将输出流生成为一个或多个输出主题，从而将输入流有效地转换为输出流。
-
连接器API允许构建和运行可重复使用的生产者或消费者，将Kafka主题连接到现有的应用程序或数据系统。例如，连接到关系数据库的连接器可能会捕获对表的每个更改。
在Kafka中，客户端和服务器之间的通信是通过一种简单的，高性能的，语言无关的TCP协议完成的。该协议是版本化的，新版本保持与旧版本的向后兼容性。我们为Kafka提供Java客户端，但客户端可以使用多种语言。
主题和日志
让我们首先深入了解一下的核心抽象概念-- Topic
tipic是记录发布到的类别或feed名称。卡夫卡的topic始终是多用户的;也就是说，一个主题可以有零个，一个或多个订阅写入数据的消费者。
对于每个主题，Kafka集群都维护一个分区日志，如下所示：
每个分区都是一个有序的，不可变的记录序列，不断追加到结构化的提交日志中。分区中的记录每个分配一个连续的id号，称为偏移量，用于唯一标识分区内的每条记录。
Kafka集群使用可配置的保留期持续保留所有已发布的记录 - 不管它们是否已被消费。例如，如果保留策略设置为两天，则在记录发布后的两天内，它可用于消费，之后将被丢弃以释放空间。卡夫卡的性能不会不会在数据量变大的时候变差，因此长时间存储数据不成问题。
实际上，保留在每个消费者基础上的唯一元数据是该消费者在日志中的偏移量或位置。这个偏移量是由消费者控制的：消费者通常会在读取记录时线性地推进其偏移量，但实际上，由于位置由消费者控制，因此它可以按照喜欢的任何顺序消费记录。例如，消费者可以重置为较旧的偏移量以重新处理来自过去的数据，或者跳至最近的记录并从当前位置开始消费。
这种功能的组合意味着卡夫卡消费者非常轻量级 - 他们可以来来去去，对集群或其他消费者没有太大影响。例如，您可以使用我们的命令行工具来“追查”任何主题的内容，而无需更改任何现有客户使用的内容。
日志中的分区有多种用途。首先，它们允许日志的大小超出适合单个服务器的大小。每个单独的分区必须适合承载它的服务器，但是一个topic可能有很多分区，因此它可以处理任意数量的数据。其次，它们作为并行的单位 - 更重要的是这一点。
分布式
日志的分区分布在Kafka集群中的服务器上，每个服务器处理数据并请求共享分区。每个分区都通过可配置数量的服务器进行复制以实现容错。
每个分区都有一台服务器作为leader，零个或多个服务器作为followers。leader处理分区的所有读取和写入请求，而followers被动地复制leader。如果leader失败，其中一个follower将自动成为新leader。每个服务器都充当其中一些分区的leader和其他人的followers，因此负载在集群内平衡良好。
区域复制
Kafka MirrorMaker为您的群集提供地理复制支持。借助MirrorMaker，消息可以跨多个数据中心或云区域进行复制。您可以在主动/被动场景中将其用于备份和恢复;或者在主动/主动方案中将数据放置得更靠近用户，或支持数据本地化要求。
Provider
生产者将数据发布到他们选择的主题。生产者负责选择将哪个记录分配给主题中的哪个分区。这可以以循环方式完成，只是为了平衡负载，或者可以根据某种语义分区功能（例如基于记录中的某个键）完成。更多关于在第二次使用分区！
consumer
消费者用消费者组名称标记自己，并且发布到主题的每个记录都被传送到每个订阅消费者组中的一个消费者实例。消费者实例可以在单独的进程中或在单独的机器上。
如果所有消费者实例具有相同的消费者组，则记录将有效地在消费者实例上进行负载均衡。
如果所有消费者实例具有不同的消费者组，则每条记录都将广播给所有消费者进程。
两个服务器Kafka集群托管四个分区（P0-P3）和两个消费者组。消费者组A有两个消费者实例，而组B有四个消费者实例。
然而，更常见的是，我们发现主图的消费者群体很少，每个“逻辑用户”都有一个。每个组由许多消费者实例组成，具有可扩展性和容错性。这只不过是发布 - 订阅语义，订阅者是一群消费者而不是一个进程。
在Kafka中实现消费的方式是将日志中的分区分配给消费者实例，以便每个实例在任何时间点都是“公平分享”分区的独占消费者。这个维护组中成员资格的过程是由Kafka协议动态处理的。如果新实例加入该组，则他们将接管来自该组的其他成员的一些分区;如果一个实例死亡，其分区将分配给其余实例。
卡夫卡只提供一个分区内记录的总顺序，而不是主题中不同分区之间的顺序。按分区排序与按键分区数据的能力相结合，足以满足大多数应用程序的需求。但是，如果您需要全部订单而不是记录，则可以通过仅有一个分区的主题来实现，但这意味着每个消费者组只有一个消费者进程。
多租户
您可以将Kafka部署为多租户解决方案。通过配置哪些主题可以产生或使用数据来启用多租户。还有配额操作支持。管理员可以根据请求定义和执行配额以控制客户端使用的代理资源。有关更多信息，请参阅安全性文档。
担保
kafka提供了以下的高层次的保证:
-
由生产者发送到特定主题分区的消息将按照它们发送的顺序附加。也就是说，如果记录M1和M2由同一个生产者发送，并且M1被首先发送，则M1将具有比M2更低的偏移并且出现在日志中较早的地方。
-
消费者实例按照它们存储在日志中的顺序查看记录。
-
对于具有复制因子N的主题，我们将容忍多达N-1个服务器故障，而不会丢失任何提交给日志的记录。
有关这些保证的更多详细信息在文档的设计部分给出。
使用kafka作为消息系统
卡夫卡的流概念如何与传统的企业消息传递系统进行对比？
消息传统上有两种模式：队列和发布 - 订阅。在队列模式中，消费者池可以从服务器读取，并且每条记录都会转到其中的一个;在发布 - 订阅模式中记录被广播给所有消费者。这两种模式都有优势和劣势。队列的优势在于它允许您将多个用户实例中的数据处理分开，从而扩展您的处理。不幸的是，队列不是多用户的,一旦一个进程读取之后,数据就消失了。发布 - 订阅允许您将数据广播到多个进程，但无法进行扩展处理，因为每条消息都发送给每个订阅者。
卡夫卡的消费者组概念概括了这两个概念。与队列一样，消费者组允许您划分一系列流程（消费者组的成员）的处理。与发布 - 订阅一样，卡夫卡允许您向多个消费者群体广播消息。
卡夫卡的模型的优点是，每个主题都有两个属性，它可以扩展的处理，也是多用户，有没有必要选择一个或另一个。
同时,Kafka也比传统的消息系统有更强大的顺序保障。
传统队列在服务器上按顺序保留记录，并且如果多个使用者从队列中消耗，则服务器按照它们存储的顺序提交记录。但是，尽管服务器按顺序提交记录，但记录会异步传送给消费者，因此它们可能会针对不同的消费者按顺序到达。这实际上意味着在并行消耗的情况下记录的排序会丢失。消息传递系统通常具有“排他消费者”的概念，只允许一个进程从队列中消耗，但这当然意味着处理中没有并行性。
卡夫卡做得更好。通过在主题内部有一个并行概念-分区概念，Kafka能够在消费者流程池中提供顺序保证和负载均衡。这是通过将主题中的分区分配给使用者组中的使用者来实现的，以便每个分区仅由组中的一位使用者使用。通过这样做，我们确保消费者是该分区的唯一读者，并按顺序使用数据。由于有很多分区，这仍然可以平衡许多消费者实例的负载。但请注意，消费者组中的消费者实例不能多于分区。
使用kafka作为存储系统
任何允许发布消息与消费消息分离的消息队列都可以充当存储系统的空中消息。卡夫卡的不同之处在于它是一个非常好的存储系统。
写入Kafka的数据写入磁盘并进行复制以实现容错。 Kafka允许生产者等待确认，以便写入在完全复制之前不会被认为是完整的，并且即使写入的服务器失败也能保证持久化。
Kafka磁盘结构使用的规模很大 - 无论您在服务器上有50 KB还是50 TB的持久化数据，Kafka都会执行相同的操作。
作为认真考虑存储并允许客户端控制其读取位置的结果，您可以将Kafka视为一种专用于高性能，低延迟提交日志存储，复制和传播的专用分布式文件系统。
有关Kafka提交日志存储和复制设计的详细信息，请阅读本页。
kafka的流处理:
仅读取，写入和存储数据流是不够的，目的是启用流的实时处理。
在Kafka中，流处理器是指从输入主题获取连续数据流，对该输入执行一些处理并生成连续数据流以输出主题的任何内容。
例如，零售应用程序可能会接受销售和装运的输入流，并输出一系列重新排序和根据此数据计算出的价格调整。
可以直接使用生产者API和消费者API进行简单的处理。然而，对于更复杂的转换，Kafka提供完全集成的Streams API。这允许构建应用程序进行非平凡的处理，从而计算聚合关闭流或将流连接在一起。
这个工具有助于解决这类应用程序面临的难题：处理无序数据，重新处理代码更改的输入，执行有状态的计算等。
流API基于Kafka提供的核心原语构建：它使用生产者API和消费者API输入，使用Kafka进行有状态存储，并在流处理器实例之间使用相同的组机制来实现容错。
把碎片聚合起来
消息传递，存储和流处理的这种组合可能看起来很不寻常，但对于Kafka作为流式传输平台的角色来说，这是非常重要的。
像HDFS这样的分布式文件系统允许存储用于批处理的静态文件。这样的系统允许存储和处理过去的历史数据。
传统的企业消息传递系统允许处理订阅后将会到来的消息。以这种方式构建的应用程序处理将来的数据。
Kafka结合了这两种功能，而且这两种组合对于Kafka用作流式传输应用平台和流式数据管道都非常重要。
通过将存储和低延迟订阅相结合，流式应用可以以相同的方式处理过去和未来的数据。这是一个单一的应用程序可以处理历史的，存储的数据，而不是在它达到最后一个记录时结束，它可以在将来的数据到达时继续处理。这是流处理的一般概念，包括批处理以及消息驱动的应用程序。
同样，对于流式数据流水线，订阅实时事件的组合使得可以将Kafka用于非常低延迟的流水线;但可靠地存储数据的能力可以将其用于必须保证数据交付的关键数据，或者与只能定期加载数据的离线系统集成，或者可能在较长时间内停机进行维护。流处理设施可以在数据到达时进行转换。
有关Kafka提供的担保，API和功能的更多信息，请参阅其余文档