详细剖析 Kafka 架构及组件
1. kafka 架构
生产者 API
允许应用程序发布记录流至一个或者多个 kafka 的主题（topics）。
消费者 API
允许应用程序订阅一个或者多个主题，并处理这些主题接收到的记录流。
3。 StreamsAPI
允许应用程序充当流处理器（stream processor），从一个或者多个主题获取输入流，并生产一个输出流到一个或 者多个主题，能够有效的变化输入流为输出流。
ConnectAPI
允许构建和运行可重用的生产者或者消费者，能够把 kafka 主题连接到现有的应用程序或数据系统。例如：一个连接到关系数据库的连接器可能会获取每个表的变化。
注：在 Kafka 2.8.0 版本，移除了对 Zookeeper 的依赖，通过 KRaft 进行自己的集群管理，使用 Kafka 内部的 Quorum 控制器来取代 ZooKeeper，因此用户第一次可在完全不需要 ZooKeeper 的情况下执行 Kafka，这不只节省运算资源，并且也使得 Kafka 效能更好，还可支持规模更大的集群。
过去 Apache ZooKeeper 是 Kafka 这类分布式系统的关键，ZooKeeper 扮演协调代理的角色，所有代理服务器启动时，都会连接到 Zookeeper 进行注册，当代理状态发生变化时，Zookeeper 也会储存这些数据，在过去，ZooKeeper 是一个强大的工具，但是毕竟 ZooKeeper 是一个独立的软件，使得 Kafka 整个系统变得复杂，因此官方决定使用内部 Quorum 控制器来取代 ZooKeeper。
这项工作从去年 4 月开始，而现在这项工作取得部分成果，用户将可以在 2.8 版本，在没有 ZooKeeper 的情况下执行 Kafka，官方称这项功能为 Kafka Raft 元数据模式（KRaft）。在 KRaft 模式，过去由 Kafka 控制器和 ZooKeeper 所操作的元数据，将合并到这个新的 Quorum 控制器，并且在 Kafka 集群内部执行，当然，如果使用者有特殊使用情境，Quorum 控制器也可以在专用的硬件上执行。
好，说完在新版本中移除 zookeeper 这个事，咱们在接着聊 kafka 的其他功能：
kafka 支持消息持久化，消费端是主动拉取数据，消费状态和订阅关系由客户端负责维护，消息消费完后，不会立即删除，会保留历史消息。因此支持多订阅时，消息只会存储一份就可以。
broker：kafka 集群中包含一个或者多个服务实例（节点），这种服务实例被称为 broker（一个 broker 就是一个节点/一个服务器）；
topic：每条发布到 kafka 集群的消息都属于某个类别，这个类别就叫做 topic；
partition：partition 是一个物理上的概念，每个 topic 包含一个或者多个 partition；
segment：一个 partition 当中存在多个 segment 文件段，每个 segment 分为两部分，.log 文件和 .index 文件，其中 .index 文件是索引文件，主要用于快速查询， .log 文件当中数据的偏移量位置；
producer：消息的生产者，负责发布消息到 kafka 的 broker 中；
consumer：消息的消费者，向 kafka 的 broker 中读取消息的客户端；
consumer group：消费者组，每一个 consumer 属于一个特定的 consumer group（可以为每个 consumer 指定 groupName）；
.log：存放数据文件；
.index：存放.log 文件的索引数据。
2. Kafka 主要组件
1. producer（生产者）
producer 主要是用于生产消息，是 kafka 当中的消息生产者，生产的消息通过 topic 进行归类，保存到 kafka 的 broker 里面去。
2. topic（主题）
kafka 将消息以 topic 为单位进行归类；
topic 特指 kafka 处理的消息源（feeds of messages）的不同分类；
topic 是一种分类或者发布的一些列记录的名义上的名字。kafka 主题始终是支持多用户订阅的；也就是说，一 个主题可以有零个，一个或者多个消费者订阅写入的数据；
在 kafka 集群中，可以有无数的主题；
生产者和消费者消费数据一般以主题为单位。更细粒度可以到分区级别。
3. partition（分区）
kafka 当中，topic 是消息的归类，一个 topic 可以有多个分区（partition），每个分区保存部分 topic 的数据，所有的 partition 当中的数据全部合并起来，就是一个 topic 当中的所有的数据。
一个 broker 服务下，可以创建多个分区，broker 数与分区数没有关系；
在 kafka 中，每一个分区会有一个编号：编号从 0 开始。
每一个分区内的数据是有序的，但全局的数据不能保证是有序的。（有序是指生产什么样顺序，消费时也是什么样的顺序）
4. consumer（消费者）
consumer 是 kafka 当中的消费者，主要用于消费 kafka 当中的数据，消费者一定是归属于某个消费组中的。
5. consumer group（消费者组）
消费者组由一个或者多个消费者组成，同一个组中的消费者对于同一条消息只消费一次。
每个消费者都属于某个消费者组，如果不指定，那么所有的消费者都属于默认的组。
每个消费者组都有一个 ID，即 group ID。组内的所有消费者协调在一起来消费一个订阅主题( topic)的所有分区(partition)。当然，每个分区只能由同一个消费组内的一个消费者(consumer)来消费，可以由不同的消费组来消费。
partition 数量决定了每个 consumer group 中并发消费者的最大数量。如下图：
如上面左图所示，如果只有两个分区，即使一个组内的消费者有 4 个，也会有两个空闲的。
如上面右图所示，有 4 个分区，每个消费者消费一个分区，并发量达到最大 4。
在来看如下一幅图：
如上图所示，不同的消费者组消费同一个 topic，这个 topic 有 4 个分区，分布在两个节点上。左边的 消费组 1 有两个消费者，每个消费者就要消费两个分区才能把消息完整的消费完，右边的 消费组 2 有四个消费者，每个消费者消费一个分区即可。
总结下 kafka 中分区与消费组的关系：
消费组： 由一个或者多个消费者组成，同一个组中的消费者对于同一条消息只消费一次。某一个主题下的分区数，对于消费该主题的同一个消费组下的消费者数量，应该小于等于该主题下的分区数。
如：某一个主题有 4 个分区，那么消费组中的消费者应该小于等于 4，而且最好与分区数成整数倍 1 2 4 这样。同一个分区下的数据，在同一时刻，不能同一个消费组的不同消费者消费。
总结：分区数越多，同一时间可以有越多的消费者来进行消费，消费数据的速度就会越快，提高消费的性能。
6. partition replicas（分区副本）
kafka 中的分区副本如下图所示：
副本数（replication-factor）：控制消息保存在几个 broker（服务器）上，一般情况下副本数等于 broker 的个数。
一个 broker 服务下，不可以创建多个副本因子。创建主题时，副本因子应该小于等于可用的 broker 数。
副本因子操作以分区为单位的。每个分区都有各自的主副本和从副本；
主副本叫做 leader，从副本叫做 follower（在有多个副本的情况下，kafka 会为同一个分区下的所有分区，设定角色关系：一个 leader 和 N 个 follower），处于同步状态的副本叫做 in-sync-replicas(ISR);
follower 通过拉的方式从 leader 同步数据。消费者和生产者都是从 leader 读写数据，不与 follower 交互。
副本因子的作用：让 kafka 读取数据和写入数据时的可靠性。
副本因子是包含本身，同一个副本因子不能放在同一个 broker 中。
如果某一个分区有三个副本因子，就算其中一个挂掉，那么只会剩下的两个中，选择一个 leader，但不会在其他的 broker 中，另启动一个副本（因为在另一台启动的话，存在数据传递，只要在机器之间有数据传递，就会长时间占用网络 IO，kafka 是一个高吞吐量的消息系统，这个情况不允许发生）所以不会在另一个 broker 中启动。
如果所有的副本都挂了，生产者如果生产数据到指定分区的话，将写入不成功。
lsr 表示：当前可用的副本。
7. segment 文件
一个 partition 当中由多个 segment 文件组成，每个 segment 文件，包含两部分，一个是 .log 文件，另外一个是 .index 文件，其中 .log 文件包含了我们发送的数据存储，.index 文件，记录的是我们.log 文件的数据索引值，以便于我们加快数据的查询速度。
索引文件与数据文件的关系
既然它们是一一对应成对出现，必然有关系。索引文件中元数据指向对应数据文件中 message 的物理偏移地址。
比如索引文件中 3,497 代表：数据文件中的第三个 message，它的偏移地址为 497。
再来看数据文件中，Message 368772 表示：在全局 partiton 中是第 368772 个 message。
注：segment index file 采取稀疏索引存储方式，减少索引文件大小，通过 mmap（内存映射）可以直接内存操作，稀疏索引为数据文件的每个对应 message 设置一个元数据指针，它比稠密索引节省了更多的存储空间，但查找起来需要消耗更多的时间。
.index 与 .log 对应关系如下：
上图左半部分是索引文件，里面存储的是一对一对的 key-value，其中 key 是消息在数据文件（对应的 log 文件）中的编号，比如“1,3,6,8……”，分别表示在 log 文件中的第 1 条消息、第 3 条消息、第 6 条消息、第 8 条消息……
那么为什么在 index 文件中这些编号不是连续的呢？这是因为 index 文件中并没有为数据文件中的每条消息都建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。但缺点是没有建立索引的 Message 也不能一次定位到其在数据文件的位置，从而需要做一次顺序扫描，但是这次顺序扫描的范围就很小了。
value 代表的是在全局 partiton 中的第几个消息。
以索引文件中元数据 3,497 为例，其中 3 代表在右边 log 数据文件中从上到下第 3 个消息，497 表示该消息的物理偏移地址（位置）为 497(也表示在全局 partiton 表示第 497 个消息-顺序写入特性)。
log 日志目录及组成 kafka 在我们指定的 log.dir 目录下，会创建一些文件夹；名字是 （主题名字-分区名） 所组成的文件夹。 在（主题名字-分区名）的目录下，会有两个文件存在，如下所示：
在目录下的文件，会根据 log 日志的大小进行切分，.log 文件的大小为 1G 的时候，就会进行切分文件；如下：
在 kafka 的设计中，将 offset 值作为了文件名的一部分。
segment 文件命名规则：partion 全局的第一个 segment 从 0 开始，后续每个 segment 文件名为上一个全局 partion 的最大 offset（偏移 message 数）。数值最大为 64 位 long 大小，20 位数字字符长度，没有数字就用 0 填充。
通过索引信息可以快速定位到 message。通过 index 元数据全部映射到内存，可以避免 segment File 的 IO 磁盘操作；
通过索引文件稀疏存储，可以大幅降低 index 文件元数据占用空间大小。
稀疏索引：为了数据创建索引，但范围并不是为每一条创建，而是为某一个区间创建；好处：就是可以减少索引值的数量。不好的地方：找到索引区间之后，要得进行第二次处理。
8. message 的物理结构
生产者发送到 kafka 的每条消息，都被 kafka 包装成了一个 message
message 的物理结构如下图所示：
所以生产者发送给 kafka 的消息并不是直接存储起来，而是经过 kafka 的包装，每条消息都是上图这个结构，只有最后一个字段才是真正生产者发送的消息数据。
版权声明: 本文为 InfoQ 作者【五分钟学大数据】的原创文章。
原文链接:【http://xie.infoq.cn/article/0f050035e10e9aef5c1f5c866】。文章转载请联系作者。
InfoQ签约作者 2020.11.10 加入
文章首发于公众号：五分钟学大数据。大数据领域原创技术号，深入大数据技术
评论