Kafka 基础知识

Apache Kafka 源于 LinkedIn，是一个分布式的发布-订阅消息系统。最初 LinkedIn 开发 Kafka 的目的，是将 Kafka 作为内部的活动流和运营数据处理管道处理的基础，因此，所开发的 Kafka 特点是基于 Pull 模式来处理消息，追求高吞吐量。2010 年，LinkedIn 将 Kafka 贡献给 Apache，现在 Kafka 已经成为应用非常广泛的一个消息中间件。

Kafka 使用 Scala 和 Java 进行编写，具有快速、可扩展、高吞吐量、内置分区、支持数据副本和可容错等特性，能够支撑海量数据的高效传递。同时 Kafka 支持消息持久化，从而能够保障对数据高效处理的同时，防止消息数据的丢失。因此，Kafka 非常适合在大规模消息处理场景中使用。

Kakfa 的基础术语如下：

• 主题：Topic

在 Kafka 中将每一个不同类别的消息称为一个主题 Topic。在物理上，不同主题（Topic）的消息是分开存储的。在逻辑上，同一个主题（Topic）的消息可能保存在一个或多个代理（Broker）中，但对于生产者或消费者来说，只需指定消息的主题（Topic）就可生产或消费数据，而不用关心消息数据到底存于何处。

• 生产者：Producer

生产者也就是消息的发布者。负责将消息发布到 Kafka 中的某个主题（Topic）中，消息代理（Broker）在接收到生产者所发送的消息后，将该消息追加到当前分区中。生产者在发布消息的时候也可以选择将消息发布到主题上的哪一个分区上。

• 消息代理：Broker

生产者所发布的消息将保存在一组 Kafka 服务器中，称之为 Kafka 集群。而集群中的每一个 Kafka 服务器节点就是一个消息代理 Broker。消费者通过消息代理从中获取所订阅的消息并进行消费。

• 消息分区：Partition

主题所发布的消息数据将会被分割为一个或多个分区（Partition），每一个分区的数据又可以使用多个 Segment 文件进行存储。在一个分区中的消息数据是有序的，而多个分区之间则没有消息数据顺序。如果一个主题的数据需要严格保证消息的消费顺序，那么需要将分区数目设为 1。

当生产者将消息存储到一个分区中时，Kafka 会为每条消息数据建立一个唯一索引号（index），这个索引号称为偏移量（offset）。对于消费者来说都会在本地保存该 offset，这样当消费者正常消费时，相应本地的偏移量也会增加。同时消费者可以自己控制该偏移量，以便进行消息的重新消费等处理。Kafka 的这种设计对消费者来说非常实用。

当新的消息数据追加到分区中时，Kafka 集群就会在不同的消息代理（Broker）之间做个备份，从而保证了消息数据的可靠性。此外，Kafka 还支持实时的流处理。通过流处理可以持续从某个主题中获取输入数据，并进行处理加工，然后将其写入输出主题中。对于复杂的转换，Kafka 提供了 Streams API 来辅助流处理。通过这种实时的流处理，可以构建聚合计算或者将流连接到一起，形成复杂的应用。

因为 Kafka 是一个分布式的消息系统，消息代理（Broker）、消费者（Consumer）等都需要 ZooKeeper 来提供分布式支持，因此在启动 Kafka 服务器之前需要先启动一个 ZooKeeper 服务。