Kafka系列：Kafka入门 | 飙戈的博客

type

status

date

slug

summary

1、Kafka是什么

Kafka 起初是由 LinkedIn 公司开发的一套发布与订阅模式的分布式消息系统，后来加入 Stream、Connect 等组件后不只是一个单纯的消息引擎系统，而是能够实现精确一次（Exactly-once）处理语义的实时流处理平台。Kafka 具有三个重要的角色属性：

消息系统：kafka 与传统的消息中间件都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯性消费的功能。

存储系统：kafka 把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效的降低了消息丢失的风险。这得益于其消息持久化和多副本机制。也可以将 kafka 作为长期的存储系统来使用，只需要把对应的数据保留策略设置为“永久”或启用主题日志压缩功能。

流式处理平台：kafka 为流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理框架，比如窗口、连接、变换和聚合等各类操作。类似于 Apache Storm、Apache Spark Streaming 或 Apache Flink 等组件的功能。

Kafka 服务器端的代码完全由 Scala 语言编写的，Scala 是一门面向对象编程和函数式编程的语言，代码最终被编译为 .class 文件运行在JVM虚拟机中，所以 Scala 属于 JVM 体系的语言。Kafka 新版客户端代码则由 Java 语言编写，包括 Kafka Connect 和主流 API。所以 Kafka 的版本号一般写成 kafka_2.11-2.2.1 这种格式：

2.11为 scala 版本号。

2.2.1 为 kafka 版本号。

第一个 2 表示大版本号
第二个 2 表示小版本号
最后一个 1 表示修订号

Kafka目前总共演进了 7 个大版本，分别是 0.7、0.8、0.9、0.10、0.11、1.0 和 2.0，每个版本的功能特性如下图所示。我们在使用的时候尽量保持服务器端版本和客户端版本一致。

Kafka 也存在由多个组织或公司发布不同版的 Kafka：

Apache Kafka：也称社区版 Kafka。优势在于迭代速度快，社区响应度高，使用它可以让你有更高的把控度；缺陷在于仅提供基础核心组件，缺失一些高级的特性。

Confluent Kafka：Confluent 公司提供的 Kafka。优势在于集成了很多高级特性且由 Kafka 原班人马打造，质量上有保证；缺陷在于相关文档资料不全，普及率较低，没有太多可供参考的范例。

CDH/HDP Kafka：大数据云公司提供的 Kafka，内嵌 Apache Kafka。优势在于操作简单，节省运维成本；缺陷在于把控度低，演进速度较慢。

不论是哪种 Kafka，本质上都内嵌了最核心的 Apache Kafka，也就是社区版 Kafka。我们后面的介绍也是基于 Apache Kafka 版本。

2、Kafka基本概念

一个典型的 Kafka 包含若干 Producer、若干 Broker、若干 Consumer 以及一个 Zookeeper 集群。Zookeeper 是 Kafka 用来负责集群元数据管理、控制器选举等操作的。Producer 是负责将消息发送到 Broker 的，Broker 负责将消息持久化到磁盘，而 Consumer 是负责从 Broker 订阅并消费消息。Kafka 体系结构如下所示：

2.1 生产者（Producer）与消费者（Consumer）

对于 Kafka 来说客户端有两种基本类型：生产者（Producer）和 消费者（Consumer）。除此之外，还有用来做数据集成的 Kafka Connect API 和流式处理的 Kafka Streams 等高阶客户端，但这些高阶客户端底层仍然是生产者和消费者 API，只不过是在上层做了封装。

Producer：消息生产者，向 Kafka Broker 发消息的客户端。

Consumer：消息消费者，从 Kafka Broker 取消息的客户端。

Consumer Group：消费者组，Topic 以 Consumer Group 为单位被消费，即 Consumer Group 是逻辑上的一个订阅者。Consumer Group 的作用是提高消费能力，它具有以下约束：

一个 Consumer Group 包含一到多个 Consumer，一个 Consumer 也可以归属到多个 Consumer Group 下，但任意的 Consumer 一定属于某个 Consumer Group。
同个 Topic 的一个 Partition 只能由组内一个 Consumer 消费，每个 Consumer 负责消费同个 Topic 的一到多个 Partition。Consumer Group 之间的消费互不影响。

同一个 Consumer Group 中的 Consumer 个数最好不要超过 Topic 的 Partition 数，如果超过，那么将有 Consumer 处于闲置状态。

2.2 Broker 和集群（Cluster）

Broker：一个 Kafka 服务器就是一台 Broker。Broker 是存储 Topic 消息的物理媒介，它接受 Producer 发送的消息并存入磁盘，同时服务 Consumer 拉取分区消息的请求，返回目前已经提交的消息。

Cluster：若干个 Broker 组成一个集群（Cluster），在集群内一个分区由一个 Broker 负责，这个 Broker 也称为这个分区的 Leader；当然一个分区可以被复制到多个 Broker 上来实现冗余，这样当存在 Broker 故障时可以将其分区重新分配到其他 Broker 来实现故障转移。

Controller：管理和协调整个Kafka集群，包括分配分区到 Broker、监控 Broker 故障等。每个集群只有一个 Controller。

2.3 主题（Topic）与分区（Partition）

Message：消息，用户实际数据的载体，是 Producer/Consumer 和 Broker 进行通讯的数据媒介，类似于数据库中数据行的概念。

Topic：消息以主题（Topic）来分类，每一个主题都对应一个「消息队列」，类似于数据库中数据表的概念。

Partition：保存 Topic 中的部分消息。一个 Topic 可以被分成多个 Partition 分布到多个 Broker 上，每个 Broker 保存一部分 Partition。Partition 的作用是实现扩展性，提高并发能力。

Replica：Partition 的副本，为实现备份的功能，保证集群中的某个节点发生故障时，该节点上的 Partition 数据不丢失，且 Kafka 仍然能够继续工作，Kafka 提供了副本机制，一个 Topic 的每个 Partition 都有若干个 Replica。Replica 分为一个 Leader 和若干个 Follower。

Leader：每个 Partition 多个 Replica 中的「主副本」，提供读写功能，Producer 发送数据的对象，以及 Consumer 消费数据的对象，都是 Leader。

Follower：每个 Partition 多个 Replica 中的「从副本」，提供只读功能，实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个 Follower 还会成为新的 Leader。Follower 只作为备份功能，日常不会与 Producer 和 Consumer 进行交互。

3、Kafka整体工作流程

Kafka 整体工作过程是推拉结合的方式：

发送消息：Producer 采用推（Push）模式向 Broker 集群的 Topic A 发送 Message，Message 被分配到 Topic A 下的某个 Partition 的 Leader 上，以追加（append）的方式添加到 Partition 文件上，属于顺序写磁盘，然后持久化保存在某台 Broker 上面。

消息同步：该 Partition 的其他 Follower 会从 Leader 上同步 Message，Message 会被保存到多台 Broker 上。

订阅主题：Consumer 以 Consumer Group 为单位订阅 Topic A， Topic A 下的多个 Partition 会被均匀地分配给 Consumer Group 下的多个 Consumer。 Topic A 下的一个 Partition 只能被同一个Consumer Group 下的一个 Consumer 消费，但一个 Consumer 可以消费一到多个 Partition。如果 Partition 的数量超过 Consumer 的数量，部分 Consumer 将没有 Partition 可消费。

消费消息：Consumer 会连接到 Broker 集群的某个 Broker 上，以拉（Pull）的模式从 Topic A 的某个 Paitition 的 Leader 上消费消息。