Kafka的高性能磁盘读写实现原理

灰太狼 2022-02-12 11:39 255阅读 0赞

# Kafka的高性能磁盘读写实现原理 #

2019年04月27日 22:31:36 [A-Coder][] 阅读数：94

### 一、概述 ###

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

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

目录与文件结构

*  由之前的文章分析可知，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
    
     *  1
     *  2
     *  3
     *  4
     *  5
     *  6
 *  由于在本机存在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
     *  2
     *  3
     *  4
     *  5
     *  6
     *  7
     *  8
     *  9
     *  10
     *  11
     *  12
    
    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的另外一个分区。

文件内容

*  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
    
     *  1
     *  2
     *  3
     *  4
     *  5
     *  6
 *  整个分区的数据不是由一个数据文件存放的，而是由多个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
    
     *  1
     *  2
     *  3
 *  而索引文件的文件内容也是offset的稀疏索引，从而在消费者消费消息时，broker根据消费者给定的offset，基于二分查找先在索引文件找到该offset对应的数据segment文件的位置，然后基于该位置（或往下）找到对应的数据。
 *  具体内容格式如图所示：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70]

### 三、消息写入 ###

磁盘顺序写

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

页缓存PageCache

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

### 四、消息读取 ###

*  消费者负责向broker发送从某个分区读取消费消息的请求，broker接收到消费者数据读取请求之后，根据消费者提供主题，分区与分区offset信息，找到给定的分区index和segment文件，然后通过二分查找定位到给定的数据记录，最后通过socket传输给消费者。

零拷贝读取

*  broker在从segment文件读取消息然后通过socket传输给消费者时，也是基于MMAP技术实现了零拷贝读取。

传统IO与socket传输

*  对于传统的socket文件读取传输的过程为：
    
    1.  操作系统将磁盘文件数据读取到内核空间的页缓存；
    2.  应用通过系统调用将数据从内核空间读取到用户空间的缓存中；
    3.  应用通过系统调用将数据从用户空间的缓存回写到内核空间的socket缓冲区；
    4.  操作系统将内核空间的socket缓存区中的数据写到网卡硬件缓存中，以便将数据发送出去。
 *  所以一次socket文件读取传输涉及到两次系统调用和四次拷贝。具体如图所示：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 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机制实现了磁盘文件内容的零拷贝传输。同时由于操作系统将磁盘文件内容加载到了内核页缓存，故消费者针对该磁盘文件的多次请求可以重复使用。

[A-Coder]: https://me.csdn.net/u010013573
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70]: /images/20220212/d73f58a6a7a64a27b47bf1967f582fd3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 1]: /images/20220212/f020e7b24c264b309a116f40093b4282.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/20220212/3bf0f013225844158384df90f6c423c0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwMTM1NzM_size_16_color_FFFFFF_t_70 3]: /images/20220212/a43c53cce9b342c2860694c5f0e954be.png