Kafka 基础

Kafka最早是linkedin公司用于日志处理的分布式消息队列。现在它的功能远不止消息队列这么简单。根据Kafka官网的定义，Kafka是一个分布式的流处理平台。它拥有以下三大核心功能：

• 发布和订阅数据流，类似于传统消息队列（RabbitMQ，RocketMQ）的功能
• 以容错的方式存储数据流的功能
• 实时处理数据流的功能

为了支持以上的三大核心功能，Kafka拥有四组核心API，包括：

• Producer API：用于发送数据。
• Consumer API：用于消费数据。
• Streams API：用于流处理，接受一个输入流数据经过计算后产生一个输出流数据。
• Connector API：用于连接外部应用从而构建一个可重用的producer或consumer。例如，可以通过connnetcor自动捕获数据库中数据的每一次变更。

下面的这张图阐述了Kafka目前的所有核心功能：

 

基础概念

下面是一个消息系统中的一些基本概念：

• Topic：主题，它代表着消息的类别。发布者发布一条消息必须指定topic，订阅者通过订阅topic就能消费此消息。
• Producer：消息发送者。我们将发布消息到topic的进程叫做Producer。
• Consumer: 消息消费者。我们将订阅topic，获取消息的进程叫做Consumer。Kafka中的Consumer采用poll模型。
• Broker：Kafka集群中的每一台服务器。Kafka是一个分布式集群，我们将其中每一台服务器都叫做Broker。

Producer和Consumer通过TCP协议与Kafka集群通信，Producer和Consumer可以看作是Kafka集群的客户端。Producer通过TCP协议发送消息到Kafka集群，Kafka集群再将这些消息提供给Consumer。如下图所示：

 

Topic

Topic是代表着数据的类别。一个topic可以认为是一类消息。Producer在发送消息时必须指定发往哪个topic，此后，订阅了该topic的所有Consumer都能够接收到消息。

消息在物理上是以文件的方式存储的，它们按照不同的topic进行分文件存储。每一个topic同时又被划分为多个partition，每个partition对应着一个文件（逻辑上的说法，物理上由多个segment file组成），它存储着所有发往这个partition的消息。这个文件被称为append log文件。如图：

 

我们看到，任何发布到此partition的消息都直接被添加到append log文件的尾部，每条消息在文件中保存的位置被称为偏移量（offset）。Kafka并没有额外的索引机制来存储offset，因此这意味着Kafka几乎不允许对数据进行随机读写。

Producer发送消息时可以显示地指定对应topic的partition号，从而将消息存储在特定的partition中。

Kafka将topic划分为多个partition进行存储拥有两个好处：

• 消息存储扩容。一个文件的存储大小是有限的，但在集群中的多个文件的存储就可以大大增加一个topic能够保存的消息数量。
• 并行读写。通过多个partition文件存储消息，意味着producer和consumer可以并行的读写一个topic。

Consumer消费消息时，通过指定的offset来定位下一条要读取的消息。值得注意的是，offset的维护是由Consumer全权控制的。Kafka集群只负责根据Consumer传入的offset来返回对应的消息。如下图所示：

 

Kafka不会立刻删除已经被消费的消息，它会根据broker中的配置来决定多久清理一次。当broker中配置的时间到达时，不论消息是否被消费，Kafka都会清理磁盘空间。

Producer

Producer负责将消息发送到Kafka集群的某一个topic中。同时Producer发送消息时能够指定partition号，从而将消息持久化到特定的partition中。

如果没有指定具体的partition号，那么Kafka Producer可以通过一定的算法计算出对应的partition号。具体算法如下：

• 如果待发送的消息指定了key，则对key进行hash然后映射到对应的partition号
• 如果待发送的消息没有指定key，则使用Round Robin轮询算法来确定partition号。这样可以保证数据在所有的partition上平均分配。
• 另外，Kafka Producer也支持自定义的partition分配方式。客户端提供一个实现了org.apache.kafka.clients.producer.Partitioner的类，然后将此实现类配置到Producer中即可。

Consumer

Kafka中的每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset，用于partition唯一标识一条消息。

Consumer通过移动offset来顺序读取消息。在Kafka 0.9前，offset信息保存在zookeeper的[consumers/{group}/offsets/{topic}/{partition}]目录中。而在0.9之后，所有的offset信息都保存在了Broker上的一个名为__consumer_offsets的topic中。

传统的消息队列提供两种消息消费模式：

• 队列模式：一条消息只能被多个消费者中的一个消费。
• 发布订阅模式：一条消息能够被多个消费者同时消费。

Kafka为了支持这两种消费模型，提出了消费者组（consumer group）的概念。如下图所示：

 

如图，每一个消费者不再是一个简单的订阅了某个topic的个体，多个消费者被放在了一个消费者组中。每一个消费者必须属于一个消费者组，同时一个消费者组能够拥有多个消费者。对于一个消费者组，Kafka拥有以下约束：

• 一条消息只能被一个消费者组中的一个消费者消费。
• 同一个partition中的消息只能被某个消费者组中的某个固定消费者消费。

在一个消费者组中，如果有两个消费者同时订阅了某个topic，那么该topic的某条消息一定只会被其中一个消费者消费。这就实现了队列模式。

如果将订阅了某个topic的两个消费者放在不同的消费者组下，那么该topic中的消息就能被这两个消费者同时消费。这就实现了发布订阅模式。

另外，如上图所示，在一个消费者组中，一旦某个partition被分配给了某个消费者，那么该partition就不会再分配给任何其他的同组消费者。因此如果一个consumer group中消费者数量超过了partition数量，那么一定会有多余的消费者永远收不到消息。

最后，Kafka只能够保证消息再一个分区内的消费是有序的。无法保证一个topic下（拥有多个分区）所有的消息消费都是有序的。

Replication

一个topic 的多个partition，被分布在Kafka 集群中的多个broker上。每个broker负责partition中存储的消息的读写操作。此外，Kafka还支持为每个partition设置需要备份（replicas）的个数，所有的备份partition分布Kafka集群中，以提高可用性。

既然Kafka支持replication，那么就意味着需要对多歌备份进行调度。每个partition 都有一个机器被称为"leader"，同时零个或多个机器作为follower。leader 负责所有的读写操作，follower执行leader的指令。如果leader 失效,那么将会有其他follower 来接管，成为新的leader。follower只是单调的和leader 跟进同步消息即可。因此，所有发送到Kafka集群的读写请求本质上均是针对leader的操作，leader操作完成后，发送指令给follower进行数据同步，从而实现了高可用性。