Kafka基于磁盘顺序IO和零拷贝技术实现高性能文件读写

[TOC]

一、概述

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文件的位置，然后基于该位置（或往下）找到对应的数据。

• 具体内容格式如图所示：

  
  
  

  image.png

image.png

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

1. 磁盘顺序写

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

image.png

2. 页缓存PageCache

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

image.png

2. 基于MMAP的零拷贝
操作系统提供了sendfile系统调用来支持MMAP机制，即应用只需指定需要传输的磁盘文件句柄，然后通过sendfile系统实现磁盘文件读取和从socket传输出去，其中磁盘文件的读取和从socket传输出去都是通过sendfile系统调用在内核完成的，不需要在内核空间和用户空间进行数据拷贝，具体过程如下：

1. 应用指定需要传输的文件句柄和调用sendfile系统调用（第一次系统调用）；
2. 操作系统在内核读取磁盘文件拷贝到页缓存（第一次内存拷贝）；
3. 操作系统在内核将页缓存内容拷贝到网卡硬件缓存（第二次内存拷贝）。

故整个过程涉及到一次sendfile系统调用，在内核态完成两次拷贝，在内核和用户空间之间不需要进行数据拷贝。具体过程如图所示：

image.png

所以 kafka 使用 sendfile 系统调用，具体为 Java 的 senfile 系统调用API: FileChannel的transferTo, transferFrom
，基于MMAP机制实现了磁盘文件内容的零拷贝传输（不需要在用户控件和内核空间进行数据拷贝）。

同时由于操作系统将磁盘文件内容加载到了内核页缓存，故消费者针对该磁盘文件的多次请求可以重复使用，避免重复在磁盘和内存之间进行数据拷贝。