Kafka学习（二）：基于磁盘顺序IO和零拷贝技术实现高性能文件读写

朴灿烈づ我的快乐病毒、 2022-02-13 11:25 236阅读 0赞

### 一、概述 ###

*  Kafka作为一个支持大数据量写入写出的消息队列，由于是基于Scala和Java实现的，而Scala和Java均需要在JVM上运行，所以如果是基于内存的方式，即JVM的堆来进行数据存储则需要开辟很大的堆来支持数据读写，从而会导致GC频繁影响性能。考虑到这些因素，kafka是使用磁盘而不是kafka服务器broker进程内存来进行数据存储，并且基于磁盘顺序读写和MMAP技术来实现高性能。

### 二、存储结构 ###

##### 1. 目录与文件结构 #####

*  由之前的文章分析可知，kafka是通过主题和分区来对消息进行分类的，所以在磁盘存储结构方面也是基于分区来组织的，即每个目录存放一个分区的数据，目录名为“主题-分区号”，如mytopic这个主题包含两个分区，则对应的数据目录分别为：mytopic-0和my-topic-1，如下：
    
        ./kafka-topics.sh --create --topic mytopic --partitions 2 --zookeeper localhost:2181 --replication-factor 2
        
        xyzdeMacBook-Pro:bin xyz ./kafka-topics.sh --describe --topic mytopic --zookeeper localhost:2181
        Topic:mytopic	PartitionCount:2	ReplicationFactor:2	Configs:
        	Topic: mytopic	Partition: 0	Leader: 2	Replicas: 2,1	Isr: 2,1
        	Topic: mytopic	Partition: 1	Leader: 0	Replicas: 0,2	Isr: 0,2
 *  由于在本机存在3个brokers，对应的server.properties的broker.id分别为：0, 1, 2，所以通过–describe选项查看的mytopic的详细信息可知：  
    mytopic的分区0是分区leader为broker2，同步副本为broker1和broker2；分区1的分区leader为broker0，同步副本为broker0和broker2。
 *  以上命令对应的主题mytopic存在两个分区和每个分区存在两个分区副本，其中broker0，broker1和broker2对应的数据目录在server.properties文件配置的log.dirs分别为；  
    /tmp/kafka-logs，/tmp/kafka-logs2，/tmp/kafka-logs3。所以mytopic主题对应的两个分区在磁盘上的目录结构如下：
    
        xyzdeMacBook-Pro:bin xyz cd /tmp/kafka-logs
        xyzdeMacBook-Pro:kafka-logs xyz ls
        mytopic-1				recovery-point-offset-checkpoint	replication-offset-checkpoint
        
        xyzdeMacBook-Pro:kafka-logs xyz cd /tmp/kafka-logs2/
        xyzdeMacBook-Pro:kafka-logs2 xyz ls
        mytopic-0				recovery-point-offset-checkpoint	replication-offset-checkpoint
        
        xyzdeMacBook-Pro:kafka-logs2 xyz cd /tmp/kafka-logs3
        xyzdeMacBook-Pro:kafka-logs3 xyz ls
        mytopic-0				recovery-point-offset-checkpoint
        mytopic-1				replication-offset-checkpoint
    
    1.  mytopic-0分区：在broker2对应的数据目录/tmp/kafka-logs3下面存在mytopic-0的主分区，broker1对应的数据目录/tmp/kafka-logs2存放mytopic-0的另外一个分区副本；
    2.  mytopic-1分区：在broker0对应的数据目录/tmp/kafka-logs下面存放mytopic-1的主分区，broker2对应的数据目录/tmp/kafka-logs3存放mytopic-1的另外一个分区。

##### 2. 文件内容 #####

*  kafka的数据文件是二进制格式的文件，因为二进制的文件大小相对于文本文件更小，所以可以减少数据传输，复制量，提高数据传输速度，节省网络带宽。
 *  在分区目录下面除了存在数据文件之外，还存在一个索引文件，索引文件的作用是加快在数据文件的检索速度，索引文件也是二进制文件，如下以index结尾的就是索引文件，以log结尾的就是数据文件：
    
        xyzdeMacBook-Pro:mytopic-1 xieyizun$ ls -allh
        total 0
        drwxr-xr-x  4 xieyizun  wheel   128B  4 27 09:56 .
        drwxr-xr-x  6 xieyizun  wheel   192B  4 27 20:26 ..
        -rw-r--r--  1 xieyizun  wheel    10M  4 27 09:56 00000000000000000000.index
        -rw-r--r--  1 xieyizun  wheel     0B  4 27 09:56 00000000000000000000.log
 *  整个分区的数据不是由一个数据文件存放的，而是由多个segments组成的，即上面看到的0000.log文件是其中一个segment文件，文件名是以该文件的第一个数据相对于该分区的全局offset命名的。每当segment文件达到一定的大小，则会创建一个新的segment文件，具体大小在server.properties配置：默认为1G。
    
        # The maximum size of a log segment file. When this size is reached a new log segment will be created.
        
        log.segment.bytes=1073741824
 *  而索引文件的文件内容也是offset的稀疏索引，从而在消费者消费消息时，broker根据消费者给定的offset，基于二分查找先在索引文件找到该offset对应的数据segment文件的位置，然后基于该位置（或往下）找到对应的数据。
 *  具体内容格式如图所示：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70]

### 三、消息写入：磁盘顺序写 ###

##### 1. 磁盘顺序写 #####

*  当broker接收到producer发送过来的消息时，需要根据消息的主题和分区信息，将该消息写入到该分区当前最后的segment文件中，文件的写入方式是追加写。
 *  由于是对segment文件追加写，故实现了对磁盘文件的顺序写，避免磁盘随机写时的磁盘寻道的开销，同时由于是追加写，故写入速度与磁盘文件大小无关，具体如图：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 1]

##### 2. 页缓存PageCache #####

*  虽然消息写入是磁盘顺序写入，没有磁盘寻道的开销，但是如果针对每条消息都执行一次磁盘写入，则也会造成大量的磁盘IO，影响性能。
 *  所以在消息写入方面，broker基于MMAP技术，即内存映射文件，将消息先写入到操作系统的页缓存中，由页缓存直接映射到磁盘文件，不需要在用户空间和内核空间直接拷贝消息，所以也可以认为消息传输是发送在内存中的。
 *  由于是先将消息写入到操作系统的页缓存，而页缓存数据刷新同步sync到磁盘文件是由操作系统来控制的，即操作系统通过一个内核后台线程，每5秒检查一次是否需要将页缓存数据同步到磁盘文件，如果超过指定时间或者超过指定大小则将页缓存数据同步到磁盘。所以如果在刷新到磁盘文件之前broker机器宕机了，则会导致页缓存的数据丢失。具体可以参考[：Kafka消息的存储  
    ][Kafka_]
 *  使用页缓存的另外一个好处是，如果重启了kafka服务端（这个服务重启，而不是机器重启），页缓存中的数据还是可以继续使用的。

### 四、消息读取：MMAP零拷贝 ###

*  消费者负责向broker发送从某个分区读取消费消息的请求，broker接收到消费者数据读取请求之后，根据消费者提供主题，分区与分区offset信息，找到给定的分区index和segment文件，然后通过二分查找定位到给定的数据记录，最后通过socket传输给消费者。
 *  broker在从segment文件读取消息然后通过socket传输给消费者时，也是基于MMAP技术实现了零拷贝读取。

##### 1. 传统IO与socket：两次系统调用，四次内存拷贝 #####

*  对于传统的socket文件读取传输的过程为：

1.  从磁盘读取数据  
    （1）操作系统将磁盘文件数据读取到**内核空间的页缓存**；  
    （2）应用通过系统调用将数据从内核空间读取到**用户空间的缓存**中（第一次系统调用）；
2.  将数据写入socket  
    （3）应用通过系统调用将数据从用户空间的缓存回写到**内核空间的socket缓冲区**（第二次系统调用）；  
    （4）操作系统将内核空间的socket缓存区中的数据写到**网卡硬件缓存**中，以便将数据发送出去。

*  所以一次socket文件读取传输涉及到两次系统调用和四次拷贝。具体如图所示：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 2]

##### 2. 基于MMAP的零拷贝 #####

*  操作系统提供了sendfile系统调用来支持MMAP机制，即应用只需指定需要传输的磁盘文件句柄，然后通过sendfile系统实现磁盘文件读取和从socket传输出去，其中磁盘文件的读取和从socket传输出去都是通过sendfile系统调用在内核完成的，不需要在内核空间和用户空间进行数据拷贝，具体过程如下：
    
    1.  应用指定需要传输的文件句柄和调用sendfile系统调用（第一次系统调用）；
    2.  操作系统在内核读取磁盘文件拷贝到页缓存（第一次内存拷贝）；
    3.  操作系统在内核将页缓存内容拷贝到网卡硬件缓存（第二次内存拷贝）。
 *  故整个过程涉及到一次sendfile系统调用，在内核态完成两次拷贝，在内核和用户空间之间不需要进行数据拷贝。具体过程如图所示：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 3]
 *  所以 kafka 使用 sendfile 系统调用，具体为 Java 的 senfile 系统调用API: FileChannel的transferTo, transferFrom  
    ，基于MMAP机制实现了磁盘文件内容的零拷贝传输（不需要在用户控件和内核空间进行数据拷贝）。
 *  同时由于操作系统将磁盘文件内容加载到了内核页缓存，故消费者针对该磁盘文件的多次请求可以重复使用，避免重复在磁盘和内存之间进行数据拷贝。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70]: /images/20220213/d6700d0e70c9408984383da2f7e0c4c9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 1]: /images/20220213/93588ba8632c47fb99bbc2e840abae40.png
[Kafka_]: https://www.cnblogs.com/monkeyteng/p/10221291.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 2]: /images/20220213/065e066ef6224d4e91986744eb295086.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 3]: /images/20220213/e0302398149e42a191d91990a2d48f01.png