KAFKA-01-kafka工作原理

亦凉 2023-09-29 13:48 16阅读 0赞

### 文章目录 ###

*  1:kafka定义
 *  2：kafka架构和分区
 *   *  1：kafka集群以topic形式管理集群
     *  2：topic分区
     *  3：分区与日志
 *  3：kafka消费组
 *   *  1：消费者
     *  2：消费组
 *  4：kafka中的名词概念
 *  5：kafka高性能-写入性能提升
 *   *  1:顺序写入
     *  2:mmap
 *  6：kafka高性能-读取性能提升
 *   *  1：传统IO操作
     *  2:DMA操作
     *  3：zeroCopy-零拷贝技术

# 1:kafka定义 #

> Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以收集并处理用户在网站中的所有动作流数据以及物联网设备的采样信息

> Apache Kafka是Apache软件基金会的开源的流处理平台，该平台提供了消息的订阅与发布的消息队列，一般用作系统间解耦、异步通信、削峰填谷等作用。同时Kafka又提供了Kafka streaming插件包实现了实时在线流处理。相比较一些专业的流处理框架不同，Kafka Streaming计算是运行在应用端，具有简单、入门要求低、部署方便等优点。

# 2：kafka架构和分区 #

## 1：kafka集群以topic形式管理集群 ##

Kafka集群以Topic形式负责分类集群中的Record（消息），每一个Record属于一个Topic。  
![在这里插入图片描述][3e59a567fab7463c8f4a780b9f14339e.png]

## 2：topic分区 ##

每个Topic底层都会对应一组分区的日志用于持久化Topic中的Record。同时在Kafka集群中，Topic的每一个日志的分区都一定会有1个Borker担当该分区的Leader，其他的Broker担当该分区的follower，**Leader负责分区数据的读写操作**，follower负责同步改分区的数据。这样如果分区的Leader宕机，该分区的其他follower会选取出新的leader继续负责该分区数据的读写。其中集群的中Leader的监控和Topic的部分元数据是存储在Zookeeper中.即ZK中记录谁是leader，Kafka2.8.0以后也可以配置不采用ZK；  
![在这里插入图片描述][4f75de7c0020450a8998d00b89b527a7.png]

## 3：分区与日志 ##

Kafka中所有消息是通过Topic为单位进行管理，每个Kafka中的Topic通常会有多个订阅者，负责订阅发送到改Topic中的数据。Kafka负责管理集群中每个Topic的一组日志分区数据。

生产者将数据发布到相应的Topic。负责选择将哪个记录分发送到Topic中的哪个Partition。例如可以round-robin方式完成此操作，然而这种仅是为了平衡负载。也可以根据某些语义分区功能（例如基于记录中的Key）进行此操作。

每组日志分区是一个有序的不可变的的日志序列，分区中的每一个Record都被分配了唯一的序列编号称为是offset，Kafka 集群会持久化所有发布到Topic中的Record信息，改Record的持久化时间是通过配置文件指定,默认是168小时。

log.retention.hours=168

Kafka底层会定期的检查日志文件，然后将过期的数据从log中移除，由于Kafka使用硬盘存储日志文件，因此使用Kafka长时间缓存一些日志文件是不存在问题的。Kafka中所有消息是通过Topic为单位进行管理，每个Kafka中的Topic通常会有多个订阅者，负责订阅发送到改Topic中的数据。Kafka负责管理集群中每个Topic的一组日志分区数据。

log.retention.hours=168

Kafka底层会定期的检查日志文件，然后将过期的数据从log中移除，由于Kafka使用硬盘存储日志文件，因此使用Kafka长时间缓存一些日志文件是不存在问题的。

Kafka中对Topic实现日志分区的有以下目的：

*  首先，它们允许日志扩展到超出单个服务器所能容纳的大小。每个单独的分区都必须适合托管它的服务器，但是一个Topic可能有很多分区，因此它可以处理任意数量的数据。
 *  其次每个服务器充当其某些分区的Leader，也可能充当其他分区的Follwer，因此群集中的负载得到了很好的平衡。  
    ![在这里插入图片描述][8ed0aa072a86489e8efe007082b3eec9.png]

# 3：kafka消费组 #

## 1：消费者 ##

在消费者消费Topic中数据的时候，每个消费者会维护本次消费对应分区的偏移量，消费者会在消费完一个批次的数据之后，会将本次消费的偏移量提交给Kafka集群，因此对于每个消费者而言可以随意的控制改消费者的偏移量。因此在Kafka中，消费者可以从一个topic分区中的任意位置读取队列数据，由于每个消费者控制了自己的消费的偏移量，因此多个消费者之间彼此相互独立。  
![在这里插入图片描述][08416f98b70342fb931438f222e340ae.png]

## 2：消费组 ##

消费者使用Consumer Group名称标记自己，并且发布到Topic的每条记录都会传递到每个订阅Consumer Group中的一个消费者实例。如果所有Consumer实例都具有相同的Consumer Group，那么Topic中的记录会在改ConsumerGroup中的Consumer实例进行均分消费；如果所有Consumer实例具有不同的ConsumerGroup，则每条记录将广播到所有Consumer Group进程。

更常见的是，我们发现Topic具有少量的Consumer Group，每个Consumer Group可以理解为一个“逻辑的订阅者”。每个Consumer Group均由许多Consumer实例组成，以实现可伸缩性和容错能力。这无非就是发布-订阅模型，其中订阅者是消费者的集群而不是单个进程。这种消费方式Kafka会将Topic按照分区的方式均分给一个Consumer Group下的实例，如果ConsumerGroup下有新的成员介入，则新介入的Consumer实例会去接管ConsumerGroup内其他消费者负责的某些分区，同样如果一下ConsumerGroup下的有其他Consumer实例宕机，则由改ConsumerGroup其他实例接管。

由于Kafka的Topic的分区策略，因此Kafka仅提供分区中记录的有序性，也就意味着相同Topic的不同分区记录之间无顺序。因为针对于绝大多数的大数据应用和使用场景， 使用分区内部有序或者使用key进行分区策略已经足够满足绝大多数应用场景。但是，如果您需要记录全局有序，则可以通过只有一个分区Topic来实现，尽管这将意味着每个ConsumerGroup只有一个Consumer进程。  
![在这里插入图片描述][7da9250bd88d43fa9116de6a03c25d1a.png]

# 4：kafka中的名词概念 #

1.  Producer：消息生产者，就是向 Kafka broker 发消息的客户端。
2.  Consumer：消息消费者，向 Kafka broker 取消息的客户端。
3.  Consumer Group（CG）：消费者组，由多个 consumer 组成。消费者组内每个消  
    费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不  
    影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4.  Broker：一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个  
    broker 可以容纳多个 topic。
5.  Topic：可以理解为一个队列，生产者和消费者面向的都是一个 topic。
6.  Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服  
    务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。
7.  Replica：副本。一个 topic 的每个分区都有若干个副本，一个 Leader 和若干个  
    Follower。
8.  Leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数  
    据的对象都是 Leader。
9.  Follower：每个分区多个副本中的“从”，实时从 Leader 中同步数据，保持和Leader 数据的同步。Leader 发生故障时，某个 Follower 会成为新的 Leader。

# 5：kafka高性能-写入性能提升 #

Kafka的特性之一就是高吞吐率，但是Kafka的消息是保存或缓存在磁盘上的，一般认为在磁盘上读写数据是会降低性能的，但是Kafka即使是普通的服务器，Kafka也可以轻松支持每秒百万级的写入请求，超过了大部分的消息中间件，这种特性也使得Kafka在日志处理等海量数据场景广泛应用。Kafka会把收到的消息都写入到硬盘中，防止丢失数据。为了优化写入速度Kafka采用了两个技术顺序写入和MMFile

## 1:顺序写入 ##

因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最讨厌随机I/O，最喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。这样省去了大量的内存开销以及节省了IO寻址的时间。但是单纯的使用顺序写入，Kafka的写入性能也不可能和内存进行对比，因此Kafka的数据并不是实时的写入硬盘中 。

## 2:mmap ##

Kafka充分利用了现代操作系统分页存储来利用内存提高I/O效率。Memory Mapped Files(后面简称mmap)也称为内存映射文件，在64位操作系统中一般可以表示20G的数据文件，它的工作原理是直接利用操作系统的Page实现文件到物理内存的直接映射。完成MMP映射后，用户对内存的所有操作会被操作系统自动的刷新到磁盘上，极大地降低了IO使用率。

![在这里插入图片描述][74698adcbe144373b56d727b33e37a3f.png]

# 6：kafka高性能-读取性能提升 #

Kafka服务器在响应客户端读取的时候，底层使用ZeroCopy技术，直接将磁盘无需拷贝到用户空间，而是直接将数据通过内核空间传递输出，数据并没有抵达用户空间。

## 1：传统IO操作 ##

*  1.用户进程调用read等系统调用向操作系统发出IO请求，请求读取数据到自己的内存缓冲区中。自己进入阻塞状态。
 *  2.操作系统收到请求后，进一步将IO请求发送磁盘。
 *  3.磁盘驱动器收到内核的IO请求，把数据从磁盘读取到驱动器的缓冲中。此时不占用CPU。当驱动器的缓冲区被读满后，向内核发起中断信号告知自己缓冲区已满。
 *  4.内核收到中断，使用CPU时间将磁盘驱动器的缓存中的数据拷贝到内核缓冲区中。
 *  5.如果内核缓冲区的数据少于用户申请的读的数据，重复步骤3跟步骤4，直到内核缓冲区的数据足够多为止。
 *  6.将数据从内核缓冲区拷贝到用户缓冲区，同时从系统调用中返回。完成任务  
    ![在这里插入图片描述][5ca5957ef02440aaae82b244aaaaeb51.png]

## 2:DMA操作 ##

1.用户进程调用read等系统调用向操作系统发出IO请求，请求读取数据到自己的内存缓冲区中。自己进入阻塞状态。

*  2.操作系统收到请求后，进一步将IO请求发送DMA。然后让CPU干别的活去。
 *  3.DMA进一步将IO请求发送给磁盘。
 *  4.磁盘驱动器收到DMA的IO请求，把数据从磁盘读取到驱动器的缓冲中。当驱动器的缓冲区被读满后，向DMA发起中断信号告知自己缓冲区已满。
 *  4.DMA收到磁盘驱动器的信号，将磁盘驱动器的缓存中的数据拷贝到内核缓冲区中。此时不占用CPU。这个时候只要内核缓冲区的数据少于用户申请的读的数据，内核就会一直重复步骤3跟步骤4，直到内核缓冲区的数据足够多为止。
 *  5.当DMA读取了足够多的数据，就会发送中断信号给CPU。
 *  6.CPU收到DMA的信号，知道数据已经准备好，于是将数据从内核拷贝到用户空间，系统调用返回。

> 跟IO中断模式相比，DMA模式下，DMA就是CPU的一个代理，它负责了一部分的拷贝工作，从而减轻了CPU的负担。DMA的优点就是：中断少，CPU负担低。

![在这里插入图片描述][76842dfd26ab4648a377713bcf26be24.png]

## 3：zeroCopy-零拷贝技术 ##

zeroCopy直接从原本的数据拷贝到用户空间改为，直接从内核空间拷贝到网络协议传输  
1、文件在磁盘中数据被copy到内核缓冲区  
2、从内核缓冲区copy到内核与socket相关的缓冲区。  
3、数据从socket缓冲区copy到相关协议引擎发送出去  
![在这里插入图片描述][9eb6a79eb08c42fd95ec2519d4d23f98.png]  
![在这里插入图片描述][ccc2a92b8ff348bd82aed101d53f3827.png]

[3e59a567fab7463c8f4a780b9f14339e.png]: https://img-blog.csdnimg.cn/3e59a567fab7463c8f4a780b9f14339e.png
[4f75de7c0020450a8998d00b89b527a7.png]: https://img-blog.csdnimg.cn/4f75de7c0020450a8998d00b89b527a7.png
[8ed0aa072a86489e8efe007082b3eec9.png]: https://img-blog.csdnimg.cn/8ed0aa072a86489e8efe007082b3eec9.png
[08416f98b70342fb931438f222e340ae.png]: https://img-blog.csdnimg.cn/08416f98b70342fb931438f222e340ae.png
[7da9250bd88d43fa9116de6a03c25d1a.png]: https://img-blog.csdnimg.cn/7da9250bd88d43fa9116de6a03c25d1a.png
[74698adcbe144373b56d727b33e37a3f.png]: https://img-blog.csdnimg.cn/74698adcbe144373b56d727b33e37a3f.png
[5ca5957ef02440aaae82b244aaaaeb51.png]: https://img-blog.csdnimg.cn/5ca5957ef02440aaae82b244aaaaeb51.png
[76842dfd26ab4648a377713bcf26be24.png]: https://img-blog.csdnimg.cn/76842dfd26ab4648a377713bcf26be24.png
[9eb6a79eb08c42fd95ec2519d4d23f98.png]: https://img-blog.csdnimg.cn/9eb6a79eb08c42fd95ec2519d4d23f98.png
[ccc2a92b8ff348bd82aed101d53f3827.png]: https://img-blog.csdnimg.cn/ccc2a92b8ff348bd82aed101d53f3827.png