大数据技术Kafka详解 ② | Kafka基础与架构介绍

目录

1、kafka的基本介绍

2、kafka的好处

3、分布式发布与订阅系统

4、kafka的主要应用场景

4.1、指标分析

4.2、日志聚合解决方法

4.3、流式处理

5、kafka架构

6、kafka主要组件

6.1、producer(生产者)

6.2、topic(主题)

6.3、partition(分区)

6.4、consumer(消费者)

6.5、consumergroup(消费者组)

6.6、partitionreplicas(分区副本)

6.7、segment文件

6.8、message的物理结构

C++软件异常排查从入门到精通系列教程（核心精品专栏，欢迎订阅，持续更新...）https://blog.csdn.net/chenlycly/article/details/125529931C/C++实战专栏（重点专栏，专栏文章已更新480多篇，持续更新中...）https://blog.csdn.net/chenlycly/article/details/140824370C++ 软件开发从入门到精通（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_12695902.htmlVC++常用功能开发汇总（专栏文章列表，欢迎订阅，持续更新...）https://blog.csdn.net/chenlycly/article/details/124272585开源组件及数据库技术（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_12458859.html网络编程与网络问题分享（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_2276111.html

1、kafka的基本介绍

官网：Apache Kafka

kafka是最初由linkedin公司开发的，使用scala语言编写，kafka是一个分布式、分区的、多副本的、多订阅者的日志系统（分布式MQ系统），可以用于搜索日志、监控日志、访问日志等。

Kafka is a distributed, partitioned, replicated commit log service.

它提供了类似于JMS的特性，但在设计实现上完全不同，此外它并不是JMS规范的实现。kafka对消息保存时根据Topic进行归类，发送消息者成为Producer，消息接受者成为Consumer。此外kafka集群有多个kafka实例组成，每个实例（server）成为broker。无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。

2、kafka的好处

• 可靠性：分布式的，分区，复本和容错的。
• 可扩展性：kafka消息传递系统轻松缩放，无需停机。
• 耐用性：kafka使用分布式提交日志，这意味着消息会尽可能快速的保存在磁盘上，因此它是持久的。
• 性能：kafka对于发布和定于消息都具有高吞吐量。即使存储了许多TB的消息，他也爆出稳定的性能。
• kafka非常快：保证零停机和零数据丢失。

3、分布式发布与订阅系统

Apache kafka是一个分布式发布-订阅消息系统和一个强大的队列，可以处理大量的数据，并使能够将消息从一个端点传递到另一个端点，kafka适合离线和在线消息消费。kafka消息保留在磁盘上，并在集群内复制以防止数据丢失。kafka构建在zookeeper同步服务之上。它与Apache和Spark非常好的集成，应用于实时流式数据分析。

4、kafka的主要应用场景

4.1、指标分析

kafka通常用于操作监控数据。这设计聚合来自分布式应用程序的统计信息，以产生操作的数据集中反馈。

4.2、日志聚合解决方法

kafka可用于跨组织从多个服务器收集日志，并使他们以标准的格式提供给多个服务器。

4.3、流式处理

流式处理框架（spark、storm、flink）重主题中读取数据，对齐进行处理，并将处理后的数据写入新的主题，供用户和应用程序使用，kafka的强耐久性在流处理的上下文中也非常的有用。

5、kafka架构

允许应用程序发布记录流至一个或者多个kafka的主题(topics)。

消费者API

允许应用程序订阅一个或者多个主题，并处理这些主题接收到的记录流。

StreamsAPI

允许应用程序充当流处理器(streamprocessor)，从一个或者多个主题获取输入流，并生产一个输出流到一个或者多个主题，能够有效的变化输入流为输出流。

ConnectAPI

允许构建和运行可重用的生产者或者消费者，能够把kafka主题连接到现有的应用程序或数据系统。例如：一个连接到关系数据库的连接器可能会获取每个表的变化。

过去ApacheZooKeeper是Kafka这类分布式系统的关键，ZooKeeper扮演协调代理的角色，所有代理服务器启动时，都会连接到Zookeeper进行注册。当代理状态发生变化时，Zookeeper也会储存这些数据，在过去，ZooKeeper是一个强大的工具，但是毕竟ZooKeeper是一个独立的软件，使得Kafka整个系统变得复杂，因此官方决定使用内部Quorum控制器来取代ZooKeeper。

这项工作从去年4月开始，而现在这项工作取得部分成果，用户将可以在2.8版本，在没有ZooKeeper的情况下执行Kafka，官方称这项功能为KafkaRaft元数据模式(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文件是索引文件，其中.index文件当中数据的偏移量位置；
• producer：消息的生产者,负责发布消息到kafka的broker中；
• consumer：消息的消费者,向kafka的broker中读取消息的客户端；
• consumergroup：消费者组,每一个consumer属于一个特定的consumergroup（可以为每个consumer指定groupName）；
• .log：存放数据文件；
• .index：存放.log文件的索引数据。

       在这里，给大家重点推荐一下我的几个热门畅销专栏，欢迎订阅：（博客主页还有其他专栏，可以去查看）

专栏1：（该精品技术专栏的订阅量已达到560多个，专栏中包含大量项目实战分析案例，有很强的实战参考价值，广受好评！专栏文章持续更新中，预计更新到200篇以上！欢迎订阅！）

C++软件调试与异常排查从入门到精通系列文章汇总https://blog.csdn.net/chenlycly/article/details/125529931

本专栏根据多年C++软件异常排查的项目实践，系统地总结了引发C++软件异常的常见原因以及排查C++软件异常的常用思路与方法，详细讲述了C++软件的调试方法与手段，以图文并茂的方式给出具体的项目问题实战分析实例（很有实战参考价值），带领大家逐步掌握C++软件调试与异常排查的相关技术，适合基础进阶和想做技术提升的相关C++开发人员！

考察一个开发人员的水平，一是看其编码及设计能力，二是要看其软件调试能力！所以软件调试能力（排查软件异常的能力）很重要，必须重视起来！能解决一般人解决不了的问题，既能提升个人能力及价值，也能体现对团队及公司的贡献！

专栏中的文章都是通过项目实战总结出来的，包含大量项目问题实战分析案例，有很强的实战参考价值！专栏文章还在持续更新中，预计文章篇数能更新到200篇以上！

专栏2：（本专栏涵盖了C++多方面的内容，是当前重点打造的专栏，订阅量已达200多个，专栏文章已经更新到460多篇，持续更新中...）

C/C++实战进阶（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_11931267.html

以多年的开发实战为基础，总结并讲解一些的C/C++基础与项目实战进阶内容，以图文并茂的方式对相关知识点进行详细地展开与阐述！专栏涉及了C/C++领域多个方面的内容，包括C++基础及编程要点（模版泛型编程、STL容器及算法函数的使用等）、数据结构与算法、C++11及以上新特性（不仅看开源代码会用到，日常编码中也会用到部分新特性，面试时也会涉及到）、常用C++开源库的介绍与使用、代码分享（调用系统API、使用开源库）、常用编程技术（动态库、多线程、多进程、数据库及网络编程等）、软件UI编程（Win32/duilib/QT/MFC）、C++软件调试技术（排查软件异常的手段与方法、分析C++软件异常的基础知识、常用软件分析工具使用、实战问题分析案例等）、设计模式、网络基础知识与网络问题分析进阶内容等。

专栏3：  

C++常用软件分析工具从入门到精通案例集锦汇总（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/131405795

常用的C++软件辅助分析工具有SPY++、PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clumsy、Windbg、IDA Pro等，本专栏详细介绍如何使用这些工具去巧妙地分析和解决日常工作中遇到的问题，很有实战参考价值！

专栏4：   

VC++常用功能开发汇总（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/124272585

将10多年C++开发实践中常用的功能，以高质量的代码展现出来。这些常用的高质量规范代码，可以直接拿到项目中使用，能有效地解决软件开发过程中遇到的问题。

专栏5： 

C++ 软件开发从入门到精通（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_12695902.html

根据多年C++软件开发实践，详细地总结了C/C++软件开发相关技术实现细节，分享了大量的实战案例，很有实战参考价值。

6、kafka主要组件

producer主要是用于生产消息，是kafka当中的消息生产者，生产的消息通过topic进行归类，保存到kafka的broker里面去。

6.2、topic(主题)

kafka将消息以topic为单位进行归类：

• topic特指kafka处理的消息源(feedsofmessages)的不同分类;
• topic是一种分类或者发布的一些列记录的名义上的名字。kafka主题始终是支持多用户订阅的；也就是说，一个主题可以有零个，一个或者多个消费者订阅写入的数据；
• 在kafka集群中，可以有无数的主题；
• 生产者和消费者消费数据一般以主题为单位。更细粒度可以到分区级别。

6.3、partition(分区)

kafka当中,topic是消息的归类,一个topic可以有多个分区(partition)，每个分区保存部分topic的数据，所有的partition当中的数据全部合并起来，就是一个topic当中的所有的数据。

一个broker服务下，可以创建多个分区，broker数与分区数没有关系。

在kafka中，每一个分区会有一个编号：编号从0开始。

每一个分区内的数据是有序的，但全局的数据不能保证是有序的。有序是指生产什么样顺序，消费时也是什么样的顺序。

6.4、consumer(消费者)

consumer是kafka当中的消费者，主要用于消费kafka当中的数据，消费者一定是归属于某个消费组中的。

6.5、consumergroup(消费者组)

消费者组由一个或者多个消费者组成，同一个组中的消费者对于同一条消息只消费一次。

每个消费者都属于某个消费者组，如果不指定，那么所有的消费者都属于默认的组。

每个消费者组都有一个ID，即groupID。组内的所有消费者协调在一起来消费一个订阅主题（topic）的所有分区（partition）。当然，每个分区只能由同一个消费组内的一个消费者（consumer）来消费，可以由不同的消费组来消费。

partition数量决定了每个consumergroup中并发消费者的最大数量。如下图：

再来看如下一幅图：

总结下kafka中分区与消费组的关系：

• 消费组：由一个或者多个消费者组成，同一个组中的消费者对于同一条消息只消费一次。某一个主题下的分区数，对于消费该主题的同一个消费组下的消费者数量，应该小于等于该主题下的分区数。
• 如：某一个主题有4个分区，那么消费组中的消费者应该小于等于4，而且最好与分区数成整数倍124这样。同一个分区下的数据，在同一时刻，不能同一个消费组的不同消费者消费。
• 总结：分区数越多，同一时间可以有越多的消费者来进行消费，消费数据的速度就会越快，提高消费的性能。

6.6、partitionreplicas(分区副本)

kafka中的分区副本如下图所示：

一个broker服务下，不可以创建多个副本因子。创建主题时，副本因子应该小于等于可用的broker数。副本因子操作以分区为单位的。每个分区都有各自的主副本和从副本。

主副本叫做leader，从副本叫做follower（在有多个副本的情况下，kafka会为同一个分区下的所有分区,设定角色关系:一个leader和N个follower），处于同步状态的副本叫做in-sync-replicas(ISR)，follower通过拉的方式从leader同步数据。消费者和生产者都是从leader读写数据，不与follower交互。副本因子的作用：让kafka读取数据和写入数据时的可靠性。

副本因子是包含本身，同一个副本因子不能放在同一个broker中。

如果某一个分区有三个副本因子，就算其中一个挂掉，那么只会剩下的两个中，选择一个leader，但不会在其他的broker中，另启动一个副本（因为在另一台启动的话，存在数据传递，只要在机器之间有数据传递，就会长时间占用网络IO，kafka是一个高吞吐量的消息系统，这个情况不允许发生），所以不会在另一个broker中启动。

如果所有的副本都挂了，生产者如果生产数据到指定分区的话，将写入不成功。

Isr表示：当前可用的副本。

6.7、segment文件

一个partition当中由多个segment文件组成，每个segment文件包含两部分，一个是.log文件，另外一个是.index文件。其中，.log文件包含了我们发送的数据存储，.index文件，记录的是我们.log文件的数据索引值，以便于我们加快数据的查询速度。

索引文件与数据文件的关系

既然它们是一一对应成对出现，必然有关系。索引文件中元数据指向对应数据文件中message的物理偏移地址。

比如索引文件中3，497代表：数据文件中的第三个message，它的偏移地址为497。

再来看数据文件中，Message368772表示：在全局partiton中是第368772个message

注：segmentindexfile采取稀疏索引存储方式，减少索引文件大小，通过mmap（内存映射）可以直接内存操作，稀疏索引为数据文件的每个对应message设置一个元数据指针，它比稠密索引节省了更多的存储空间，但查找起来需要消耗更多的时间。

.index与.log对应关系如下:

那么为什么在index文件中这些编号不是连续的呢？这是因为index文件中并没有为数据文件中的每条消息都建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。但缺点是没有建立索引的Message也不能一次定位到其在数据文件的位置，从而需要做一次顺序扫描，但是这次顺序扫描的范围就很小了。

value代表的是在全局partiton中的第几个消息。

以索引文件中元数据3，497为例，其中3代表在右边。

log数据文件中从上到下第3个消息，497表示该消息的物理偏移地址（位置）为497（也表示在全局partiton表示第497个消息-顺序写入特性）。

log日志目录及组成kafka在我们指定的log.dir目录下，会创建一些文件夹；名字是（主题名字-分区名）所组成的文件夹。在（主题名字-分区名）的目录下，会有两个文件存在，如下所示：

#索引⽂件
00000000000000000000.index
#⽇志内容
00000000000000000000.log

在目录下的文件，会根据log日志的大小进行切分，.log文件的大小为1G的时候，就会进行切分文件；如下：

-rw-r--r--. 1 root root 389k 1⽉ 17 18:03 00000000000000000000.index
-rw-r--r--. 1 root root 1.0G 1⽉ 17 18:03 00000000000000000000.log
-rw-r--r--. 1 root root 10M 1⽉ 17 18:03 00000000000000077894.index
-rw-r--r--. 1 root root 127M 1⽉ 17 18:03 00000000000000077894.log

在kafka的设计中，将offset值作为了文件名的一部分。

segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个全局partion的最大offset(偏移message数)。数值最大为64位long大小，20位数字字符长度，没有数字就用0填充。

通过索引信息可以快速定位到message。通过index元数据全部映射到内存，可以避免segmentFile的IO磁盘操作。

通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。

稀疏索引：为了数据创建索引，但范围并不是为每一条创建，而是为某一个区间创建。好处是可以减少索引值的数量。不好的地方是，找到索引区间之后，要得进行第二次处理。

6.8、message的物理结构

生产者发送到kafka的每条消息，都被kafka包装成了一个message。

message的物理结构如下图所示：