聊聊page cache与Kafka之间的事儿.docxVIP

聊聊page cache与Kafka之间的事儿 2021-12-30 前言 关于Kafka的一个灵魂拷问：它为什么这么快？或者说，为什么它能做到如此大的吞吐量和如此低的延迟？ 有很多文章已经对这个问题给出了回答，但本文只重点争辩其中的一个方向，即对page cache的使用。先简约地生疏一下Linux系统中的page cache（顺便也生疏一下buffer cache）。 page cache buffer cache 执行free命令，留意到会有两列名为buffers和cached，也有一行名为“-/+ buffers/cache”。 ~ free -m total used free shared buffers cachedMem: 128956 96440 32515 0 5368 39900-/+ buffers/cache: 51172 77784Swap: 16002 0 16001 其中，cached列表示当前的页缓存（page cache）占用量，buffers列表示当前的块缓存（buffer cache）占用量。用一句话来解释：page cache用于缓存文件的页数据，buffer cache用于缓存块设备（如磁盘）的块数据。页是规律上的概念，因而page cache是与文件系统同级的；块是物理上的概念，因而buffer cache是与块设备驱动程序同级的。 page cache与buffer cache的共同目的都是加速数据I/O：写数据时首先写到缓存，将写入的页标记为dirty，然后向外部存储flush，也就是缓存写机制中的write-back（另一种是write-through，Linux未接受）；读数据时首先读取缓存，假如未命中，再去外部存储读取，并且将读取来的数据也加入缓存。操作系统总是乐观地将全部空闲内存都用作page cache和buffer cache，当内存不够用时也会用LRU等算法淘汰缓存页。 在Linux 2.4版本的内核之前，page cache与buffer cache是完全分别的。但是，块设备大多是磁盘，磁盘上的数据又大多通过文件系统来组织，这种设计导致很多数据被缓存了两次，铺张内存。所以在2.4版本内核之后，两块缓存近似融合在了一起：假如一个文件的页加载到了page cache，那么同时buffer cache只需要维护块指向页的指针就可以了。只要那些没有文件表示的块，或者绕过了文件系统直接操作（如dd命令）的块，才会真正放到buffer cache里。因而，我们现在提起page cache，基本上都同时指page cache和buffer cache两者，本文之后也不再区分，直接统称为page cache。 下图近似地示出32-bit Linux系统中可能的一种page cache结构，其中block size大小为1KB，page size大小为4KB。 page cache中的每个文件都是一棵基数树（radix tree，本质上是多叉搜索树），树的每个节点都是一个页。依据文件内的偏移量就可以快速定位到所在的页，如下图所示。关于基数树的原理可以参见英文维基，这里就不细说了。 接下来就可以把Kafka扯进来了。 Kafka对page cache的利用 Kafka为什么不本人管理缓存，而非要用page cache？缘由有如下三点： JVM中一切皆对象，数据的对象存储会带来所谓object overhead，铺张空间； 假如由JVM来管理缓存，会遭到GC的影响，并且过大的堆也会拖累GC的效率，降低吞吐量； 一旦程序崩溃，本人管理的缓存数据会全部丢失。 Kafka三大件（broker、producer、consumer）与page cache的关系可以用下面的简图来表示。 producer生产消息时，会使用pwrite()系统调用【对应到Java NIO中是FileChannel.write() API】按偏移量写入数据，并且都会先写入page cache里。consumer消费消息时，会使用sendfile()系统调用【对应FileChannel.transferTo() API】，零拷贝地将数据从page cache传输到broker的Socket buffer，再通过网络传输。 图中没有画出来的还有leader与follower之间的同步，这与consumer是同理的：只需follower处在ISR中，就也能够通过零拷贝机制将数据从leader所在