前言
上一篇所说的micr-batch 其实主要是针对producer 来实现的,Kafka整体吞吐量高可不只是依赖于micr-batch这一点,还有broker端及consumer端。
Kafka高吞吐的另一个依赖因素是磁盘的高速读写、sendFile 的零拷贝,顺序访问避免了磁盘IO速度缓慢的问题。而零拷贝直接降低了网络IO的代价。下面就详细的来看看关于操作系统层面上顺序读写&速随机读写的一点现状、所谓的零拷贝技术。
与其说是Kafka 的文章,其实更像是对于Java JVM 或者 操作系统关于磁盘&文件的一种剖析:
操作系统常识
首先我们磁盘是由具体的盘片所组成的,每个盘片有两个盘面,然后盘片上有个主轴,围着主轴有一些磁道,然后同一个磁道被划分为若干个扇区,其中扇区之间有间隙隔开(间隙占10%左右),普通磁盘用的都是机械操作,外磁道和内磁道的角速度相同,所以说内磁道速度其实是小于外侧磁道的,所以通常来外磁道密度较小,然后读取速度就基本一致了。再然后,拥有相同磁头的磁道组合在一起称为一个柱面。磁盘的读取时间主要花在,循道时间、旋转延迟、传输时间上,一个7200r/min的磁盘,通常在一个磁道上的读取时间是10ms级的,异常慢。
顺序访问
顺序读写&随机读写做下差异比较的话,普通磁盘的顺序访问速度跟SSD顺序访问速度差不多一致,远超随机访问的速度(差不多 *2 +),甚至能达到内存随机访问的速度(这里举的例子是指SAS磁盘),随机读写相对于顺序读写主要时间花费在循道上,并且顺序读写会预读信息,所以速度自然就差异很大了。
![35b7b0ff427de6925e012241e7d076d4.png](https://i-blog.csdnimg.cn/blog_migrate/1ac8b911424a1206b72d1f70760560fb.jpeg)
鉴于以上原因,Kafka 采用的文件追加写入的方式,所以效率自然而然就上来了。这可能也是Kafka设计存储方式采用消息日志文件的原因,总体来说,这种写入之后就不会变,并且会大量读写操作的场景都可以使用这种方式的。在关于producer 产生消息 broker底层读写日志采用的就是这种方式,有没有很方便呢~
然后再来看看消费消息时所用到的FileChannel.transferTo
函数,FileChannel是一个接口,具体的实现逻辑在FileChannel中,有兴趣的可以大体的看一下。在JVM层面这个其实就是linux 中的sendFile 系统调用。
sendFile
关于sendFile,其实就是原本一份数据的IO是需要经过多次copy操作&内核态与用户态的上下文切换,读内核态缓存到应用程序缓存在从应用程序缓存到Socket缓存完成具体的IO操作,而sendFile系统调用零拷贝就是避免了上下文切换带来的copy操作,同时利用直接存储器访问技术(DMA)执行IO操作,避免了内核缓冲区之前的数据拷贝操作。上升到上层的语言操作,就是使用的Java中的FileChann el.transferTo方法进行实现的。(Kafka 1版本使用的是Scala,2版本开始就是使用Java 了这两者都是在JVM上执行的,本质.class 文件解析执行阶段其实是一致的)
无零拷贝的过程:硬盘 -> 内核buffer -> 用户buffer ->内核socket缓冲区 -> TCP 协议栈
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count)
in_fd
被打开是等待读数据的fd.out_fd
被打开是等待写数据的fd.Offset
是在正式开始读取数据之前应该向前偏移的byte数.count
是需要在两个fd之间“搬移”的数据的byte数.
![d2955b73087aae6d30d6ed55a652b2b8.png](https://i-blog.csdnimg.cn/blog_migrate/61ccb47f1b1824401ba38fe6bc261a8d.jpeg)
当使用sendfile零拷贝时:硬盘 -> 内核 -> TCP协议栈
![996ab4c3881cfdadf3a4d102c3ffe749.png](https://i-blog.csdnimg.cn/blog_migrate/2f9ab6cc4fb8ce57dc94e775f257e689.jpeg)
这就避免了内存切换之间的数据拷贝问题,相应的效率也就上升了,具体过程差不多就是这样。Kafka-“高吞吐”-之顺序访问与零拷贝