Kafka基础架构

kafka概述

Kafka是LinkedIn开源的分布式发布-订阅消息系统由Scala语言编写，目前归属于Apache定级项目。Kafka它提供了类似于JMS的特性，但是在设计实现上完全不同，结合JMS中的两种模式，可以有多个消费者主动拉取数据，在JMS中只有点对点模式才有消费者主动拉取数据。主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，主要应用于 大数据实时处理领域。

JMS：JMS（JAVA Message Service,Java消息服务）API是一个消息服务的标准或者说是规范，类似于JDBC(Java Database Connectivity)允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。

Kafka基础架构

网络拓扑图

名词解释

Producer ：消息生产者，就是向 kafka broker 发消息的客户端

Consumer ：消息消费者，向 kafka broker 取消息的客户端

Consumer Group （CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负 责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所 有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

Topic ：可以理解为一个队列，生产者和消费者面向的都是一个 topic；

Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；

Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本， 一个 leader 和若干个 follower。

leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower。

概念一：生产者与消费者

对于 Kafka 来说客户端有两种基本类型：

1. 生产者（Producer）
2. 消费者（Consumer）。

除此之外，还有用来做数据集成的 Kafka Connect API 和流式处理的 Kafka Streams 等高阶客户端，但这些高阶客户端底层仍然是生产者和消费者API，它们只不过是在上层做了封装。

这很容易理解，生产者（也称为发布者）创建消息，而消费者（也称为订阅者）负责消费or读取消息。

概念二：主题（Topic）与分区（Partition）

在 Kafka 中，消息以主题（Topic）来分类，每一个主题都对应一个 「消息队列」，这有点儿类似于数据库中的表。但是如果我们把所有同类的消息都塞入到一个“中心”队列中，势必缺少可伸缩性，无论是生产者/消费者数目的增加，还是消息数量的增加，都可能耗尽系统的性能或存储。

我们使用一个生活中的例子来说明：现在 A 城市生产的某商品需要运输到 B 城市，走的是公路，那么单通道的高速公路不论是在「A 城市商品增多」还是「现在 C 城市也要往 B 城市运输东西」这样的情况下都会出现「吞吐量不足」的问题。所以我们现在引入分区（Partition）的概念，类似“允许多修几条道”的方式对我们的主题完成了水平扩展。

概念三：Broker 和集群（Cluster）

Broker的作用：

• 接收生产者的消息
• 设置偏移量
• 持久化消息到磁盘
• 为消费者提供服务

一个 Kafka 服务器也称为 Broker，它接受生产者发送的消息并存入磁盘；Broker 同时服务消费者拉取分区消息的请求，返回目前已经提交的消息。使用特定的机器硬件，一个 Broker 每秒可以处理成千上万的分区和百万量级的消息。（现在动不动就百万量级..我特地去查了一把，好像确实集群的情况下吞吐量挺高的..嗯..）

若干个 Broker 组成一个集群（Cluster），其中集群内某个 Broker 会成为集群控制器（Cluster Controller），它负责管理集群，包括分配分区到 Broker、监控 Broker 故障等。在集群内，一个分区由一个 Broker 负责，这个 Broker 也称为这个分区的 Leader；当然一个分区可以被复制到多个 Broker 上来实现冗余，这样当存在 Broker 故障时可以将其分区重新分配到其他 Broker 来负责。

当我们启用Kafka的复制机制时，此时会发生分区复制。假设首领分区所在的Broker1挂了，Broker2的分区就会接管领导权，其他消费者和生产则会重新连接到新的Broker2上。

下图是一个样例：

注意：

Kafka拥有保留消息机制，在一定期限内Kafka会保留消息。消息被消费者消费后，消息任然会进行保留，不像其他MQ一样会进行删除。

保留机制：每一个主题都可以设置自己的保留策略

​ 1.保留一定时间

​ 2.保留一定大小

​Kafka 的一个关键性质是日志保留（retention），我们可以配置主题的消息保留策略，譬如只保留一段时间的日志或者只保留特定大小的日志。当超过这些限制时，老的消息会被删除。我们也可以针对某个主题单独设置消息过期策略，这样对于不同应用可以实现个性化。

酷客网相关文章：

• Kafka消息队列
• Kafka模拟集群宕机
• Kafka集群搭建测试