随着数据量的日益增长，需要工具来处理海量数据。这就是为什么需要了解Apache Kafka，一个发布-订阅消息系统，可以用它来构建分布式应用。它具有可扩展性和容错性，使其适合支持实时和高容量的数据流。因此，Apache Kafka被LinkedIn、Twitter、Airbnb等大型互联网公司使用。
现在可能有疑问。Apache Kafka增加了什么价值？它是如何工作的？在这篇文章中，将探索Apache Kafka的用例、术语、架构和工作原理。
Kafka是一个分布式发布-订阅消息系统。它有一个完整的队列，可以接收大量的消息数据。有了Kafka，应用程序可以在主题上写入和读取数据。主题是一个用于标记数据的类别。此外，应用程序可以从一个或多个类别接收消息。
Kafka将所有接收到的数据存储在磁盘存储上。然后Kafka在Kafka集群内复制数据，以防止数据丢失。
Kafka之所以可以快速处理数据有几个原因。它使用消息接收时的偏移量。它也不跟踪主题的消费者或谁消费了特定消息。对这些数据感兴趣的消费者应该跟踪这些信息。
只能在加载数据时输入一个偏移量。然后，从那个偏移量开始，Kafka将按顺序返回数据给。Kafka还有更多的速度优化，但将不在这篇文章中涵盖它们。
所有这些优化都允许Kafka处理大量数据。然而，为了更好地理解Apache Kafka的能力，首先需要了解术语。
让讨论一些在与Kafka工作时的关键术语。
还记得谈论事件流的时候吗？当然，可以同时有很多事件——需要一种方法来组织它们。对于Kafka来说，事件组织的基本单位叫做主题。
在Kafka中，主题是用户定义的类别或资源名称，数据存储和发布在这里。换句话说，一个案例只是一个事件的日志。例如，在使用Web活动跟踪时，可能有一个叫做“点击”的主题，每次用户点击特定按钮时都会接收和存储一个“点击”事件。
Kafka中的主题是分区的，这意味着将案例分成多个日志文件，这些文件可以存在于不同的Kafka代理上。这种可扩展性至关重要，因为它允许客户端应用程序同时向多个代理发布/订阅，并确保高数据可用性，因为分区在多个代理之间复制。所以，例如，如果集群中的一个Kafka代理宕机，Kafka可以安全地切换到其他代理上的复制分区。
回到网站流量用例来理解这一点。假设将“点击”主题分成三个区域。每次Web客户端向主题发布一个“点击”事件，该事件将附加到三个部分之一。如果键是事件的数据部分，它用于确定分区分配。事件被顺序添加和分区，每个事件的ID（例如，第一个事件为0，第二个事件为1等）被称为偏移量。
在第一部分中，提到分区可以存在于不同的Kafka代理上，这是Kafka防止数据丢失的基本方式。这是通过设置主题复制因子来实现的，它决定了数据在多个代理上的副本数量。
例如，复制因子为三将保持每个分区的主题副本在其他代理上有三个。为了避免在集群中同时存在准确数据和其副本时不可避免的混乱（例如，生产者将知道哪个代理用于特定分区的数据发布？），Kafka遵循领导者-追随者系统。通过这种方式，一个代理可以被设置为主题部分的领导者，其余的代理作为该部分的追随者，而只有领导者可以处理这些客户端请求。
消息系统在应用程序之间传输数据。这允许应用程序专注于数据而不是如何共享数据。
有两种类型的消息系统。一个经典的例子是点对点系统，生产者在队列中保留数据。之后，只有一个应用程序可以从队列中读取数据。读取后，消息系统会从队列中移除消息。
Apache Kafka依赖于发布-订阅消息系统。消费者可以订阅消息队列中的多个主题。然后他们接收特定于其应用程序的消息。Tutorials point网站有一个有用的图像来说明这一点。
正如名字所暗示的，代理充当买方和卖方之间的中介。Kafka代理从生产者那里接收消息并将其存储在磁盘上。它还使加载消息变得更容易。
现在让看看Apache Kafka的内部架构。
Kafka生态系统由一组生产者和消费者组成。对来说，生产者和消费者是外部参与者。内部生态系统包括Kafka的Zookeeper服务和Kafka集群。Zookeeper是一个分布式配置和同步服务，用于管理和协调Kafka代理。Zookeeper在Kafka系统中通知生产者和消费者何时添加或失败代理。
Kafka集群中的代理负责负载均衡。Zookeeper在Kafka集群中初始化多个Kafka代理以适应更高的负载。
再次，Tutorials point有一个好图像可以帮助可视化架构。
接下来，让看看Apache Kafka的一些用例。
Kafka最初的用例是能够重构用户活动跟踪渠道，作为一组实时发布和订阅的轨迹。这意味着网站活动（页面浏览、搜索或其他用户可以采取的行动）被发布到中央主题，每种活动类型都有一个。这些资源可供订阅用于各种用例，包括实时处理、监控和加载到Hadoop系统或离线数据仓库进行离线处理和报告。
活动跟踪通常非常大，因为每个用户页面浏览会生成许多活动报告。
Kafka通常用于操作监控数据。这包括从分布式应用程序聚合统计数据以创建集中的活动数据源。
许多人使用Kafka作为日志聚合解决方案的替代品。日志聚合通常从服务器收集物理日志文件，并将它们存储在中央位置（可能是文件服务器或HDFS）进行处理。Kafka抽象了文件的细节，并提供了日志或事件数据作为消息流的更清晰的抽象。这使得低延迟处理和对多个数据源和分布式数据消费的更易于支持。与以日志为中心的系统（如Scribe或Flume）相比，Kafka提供了同样好的性能，通过复制提供更强的弹性保证，并且端到端延迟要低得多。
许多Kafka用户在多阶段处理管道中处理数据，其中从Kafka主题的原始输入数据被消费，然后被聚合、丰富或以其他方式转换为新的主题，以供进一步消费或后处理。例如，推荐新闻文章的处理反馈可以从RSS feeds中抓取文章内容，并在“文章”主题下发布。进一步的处理可能会规范化或去重此内容，并将清理后的文章内容发布到新的主题；处理的最后阶段可能会尝试向用户推荐此内容。这些处理管道基于个别问题创建实时数据流图。从版本0.10.0.0开始，Apache Kafka中提供了一个轻量级但功能强大的流处理库，称为Kafka Streams，执行上述类型的数据处理。除了Kafka Streams之外，其他开源流处理工具包括Apache Storm和Apache Samza。
使用Kafka有一些优势：
在讨论了优点之后，让看看缺点：
上述缺点是设计限制，旨在提高Kafka的性能。对于期望更多灵活性的某些用例，上述限制可能会限制应用程序消费Kafka。
Apache Kafka是排序消息的极佳工具。它可以通过扩展可用代理的数量来处理大量消息数据。Zookeeper还确保一切都协调一致。然而，如果应用程序处理大量消息数据，应该考虑将Apache Kafka纳入技术栈。