Kafak概述 Kafka是由LinkedIn开发的一个分布式基于发布/订阅的消息系统，它以可水平扩展和高吞吐而被广泛使用。Kafak可以处理消费者规模的网站中的所有动作流数据，具有高性能、持久化、多副本备份、横向扩展能力。

Kafak起初基于Scala编写(现在是Scala和Java)，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。主要应用场景是：日志收集系统和消息系统。

主要设计目标如下：

以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上数据也能保证常数时间复杂度的访问性能。

高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条以上消息的传输。

支持 Kafka Server 间的消息分区，及分布式消费，同时保证每个 Partition 内的消息顺序传输。

同时支持离线数据处理和实时数据处理。

Scale out：支持在线水平扩展。

1.2、kafka版本演进 Kafka总共发布了7个大版本，分别是0.7.x、0.8.x、0.9.x、0.10.x、0.11.x、1.x及2.x版本。截止目前2021年9月25日，最新版本是Kafka 3.6.0，也是最新稳定版本。

这里简单介绍一下，kafka_2.12中的2.12表示的scala的版本，因为Kafka服务器端代码完全由Scala语音编写。”-“后面的3.0.0表示的kafka的版本信息，遵循上面的命令规则。

注：Kafka新版客户端代码完全由Java语言编写，当然，不是Scala不行了，而是社区找来了一批Java程序员而已，而之前的Scala程序员隐退罢了。

1.3、Kafak诞生背景 我们先看看 Kafka 官网给自己下的定义：

Apache Kafka is an open-source distributed event streaming platform.

翻译成中文就是：Apache Kafka 是一个开源的分布式流处理平台。

Kafka 不是一个消息系统吗？为什么被称为分布式的流处理平台呢？一定有读者会有这样的疑问，要解释这个问题，需要先从 Kafka 的诞生背景说起。

Kafka 最开始其实是 Linkedin 内部孵化的项目，在设计之初是被当做「数据管道」，用于处理以下两种场景：

1、运营活动场景：记录用户的浏览、搜索、点击、活跃度等行为。

2、系统运维场景：监控服务器的 CPU、内存、请求耗时等性能指标。

可以看到这两种数据都属于日志范畴，特点是：数据实时生产，而且数据量很大。

Linkedin 最初也尝试过用 ActiveMQ 来解决数据传输问题，但是性能无法满足要求，然后才决定自研 Kafka。所以从一开始，Kafka 就是为实时日志流而生的。了解了这个背景，就不难理解 Kafka 与流数据的关系了，以及 Kafka 为什么在大数据领域有如此广泛的应用？也是因为它最初就是为解决大数据的管道问题而诞生的。

接着再解释下：为什么 Kafka 被官方定义成流处理平台呢？它不就提供了一个数据通道能力吗，怎么还和平台扯上关系了？

这是因为 Kafka 从 0.8 版本开始，就已经在提供一些和数据处理有关的组件了，比如：

1、Kafka Streams：一个轻量化的流计算库，性质类似于 Spark、Flink。

2、Kafka Connect：一个数据同步工具，能将 Kafka 中的数据导入到关系数据库、Hadoop、搜索引擎中。

可见 Kafka 的野心不仅仅是一个消息系统，它早就在往「实时流处理平台」方向发展了。

这时候，再回来看 Kafka 的官网介绍提到的 3 种能力，也不难理解了：

1、数据的发布和订阅能力（消息队列）

2、数据的分布式存储能力（存储系统）

3、数据的实时处理能力（流处理引擎）

这样，kafka 的发展历史和定义基本缕清了。

1.4、Kafak基础架构和术语

我们先来分析相关概念

Producer：Producer即生产者，消息的产生者，是消息的入口。

Broker：Broker是kafka实例，每个服务器上有一个或多个kafka的实例，我们姑且认为每个broker对应一台服务器。每个kafka Cluster 集群内的broker都有一个不重复的编号，如图中的broker-0、broker-1等……

Topic：消息的主题，可以理解为消息的分类，kafka的数据就保存在topic。在每个broker上都可以创建多个topic。Topic在逻辑上可以被认为是一个queue，每条消息都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。

Partition：Topic的分区，每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的，partition的表现形式就是一个一个的文件夹！

Replication:每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。

Message：每一条发送的消息主体。

Consumer：消息消费者，向Kafka broker读取消息的客户端，consumer从broker拉取(pull)数据并进行处理。每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）

Consumer Group：我们可以将多个消费组组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量！

Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。