大家都知道Kafka是将数据存储于磁盘的，而磁盘读写性能往往很差，但Kafka官方测试其数据读写速率能达到600M/s，那么为什么Kafka性能会这么高呢？

首先producer往broker发送消息时，采用batch的方式即批量而非一条一条的发送，这种方式可以有效降低网络IO的请求次数，提升性能。此外这些批次消息会"暂存"在缓冲池中，避免频繁的GC问题。批量发送的消息可以进行压缩并且传输的时候可以进行高效的序列化，从而减少数据大小。

Kafka除了在producer发送消息方面做了很多优化，还有很多其他的优化，比如Kafka利用了sequence IO、PageCache、SendFile这3种处理方案：

sequence IO

首先来了解一下磁盘的特性：快速顺序读写、慢速随机读写。因为磁盘是典型的IO块设备，每次读写都会经历寻址，其中寻址中寻道是比较耗时的。随机读写会导致寻址时间延长，从而影响磁盘的读写速度。

大家有没有想过MapReduce进行shuffle的时候，为什么map端和reduce端要进行排序，不排序不也不影响正常业务的处理，排序反而因为消耗资源增加了处理时间？

以map端为例，执行过程中会产生很多小文件，这些小文件要经历归并排序等一系列处理后才会被reduce端进行处理。提前对未合并的文件进行排序正是利用了磁盘快速顺序读写的特性来提高归并排序的速度。

而Kafka在将数据持久化到磁盘时，采用只追加的顺序写，有效降低了寻址时间，提高效率。下图展示了Kafka写入数据到partition的方式：

可以看到Kafka会将数据插入到文件末尾，并且Kafka不会"直接"删除数据，而是把所有数据保存到磁盘，每个consumer会指定一个offset来记录自己订阅的topic的partition中消费的位置。当然我们可以设置策略来清理数据，比如通过参数log.retention.hours指定过期时间，当达到过期时间时，Kafka会清理数据。

PageCache

PageCache是系统级别的缓存，它把尽可能多的空闲内存当作磁盘缓存使用来进一步提高IO效率，同时当其他进程申请内存，回收PageCache的代价也很小。

当上层有写操作时，操作系统只是将数据写入PageCache，同时标记Page属性为Dirty。当读操作发生时，先从PageCache中查找，如果发生缺页才进行磁盘调度，最终返回需要的数据。

PageCache同时可以避免在JVM内部缓存数据，避免不必要的GC、以及内存空间占用。对于In-Process Cache，如果Kafka重启，它会失效，而操作系统管理的PageCache依然可以继续使用。

对应到Kafka生产和消费消息中：

producer把消息发到broker后，数据并不是直接落入磁盘的，而是先进入PageCache。PageCache中的数据会被内核中的处理线程采用同步或异步的方式写回到磁盘。

Consumer消费消息时，会先从PageCache获取消息，获取不到才回去磁盘读取，并且会预读出一些相邻的块放入PageCache，以方便下一次读取

如果Kafka producer的生产速率与consumer的消费速率相差不大，那么几乎只靠对broker PageCache的读写就能完成整个生产和消费过程，磁盘访问非常少。

SendFile

传统的网络I/O过程：

1. 操作系统从磁盘把数据读到内核区

2. 用户进程把数据从内核区copy到用户区

3. 然后用户进程再把数据写入到socket，数据流入内核区的Socket Buffer上

4. 最后把数据从socket Buffer中发送到到网卡，这样完成一次发送

可以发现，同一份数据在内核Buffer与用户Buffer之间拷贝两次：

但是通过SendFile（又称zero copy）优化后，直接把数据从内核区copy到socket，然后发送到网卡，避免了在内核Buffer与用户Buffer来回拷贝的弊端：

不仅是Kafka，Java的NIO提供的FileChannle，它的transferTo、transferFrom方法也利用了这种在内核区完成数据传输的功能。