磁盘读写的快慢取决于你怎么使用它，也就是顺序读写或者随机读写。在顺序读写的情况下，磁盘的顺序读写速度和内存持平。
如果不删除硬盘肯定会被撑满，所以Kakfa提供了两种策略来删除日志[^ log.cleanup.policy配置]：
检查当前日志文件中是否有保留时间超过设定的阈值来寻找可删除的日志分段文件集合。
log.retention.mslog.retention.minuteslog.retention.hours过期时间可以通过如上三项配置， 其配置优先级从上到下依次降低。
日志删除任务检查当前日志的大小是否超过设定的阈值[^ log.retention.bytes 配置]来寻找可删除的日志分段的文件集合。
即便是顺序写入硬盘，硬盘的访问速度还是不可能追上内存。所以Kafka的数据并不是实时的写入硬盘 ，它充分利用了现代操作系统分页存储来利用内存提高I/O效率。
Memory Mapped Files(后面简称mmap)也被翻译成 内存映射文件 ，在64位操作系统中一般可以表示20G的数据文件，它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。
完成映射之后你对物理内存的操作会被同步到硬盘上（操作系统在适当的时候）。
通过mmap，进程像读写硬盘一样读写内存（当然是虚拟机内存），也不必关心内存的大小有虚拟内存为我们兜底。
使用这种方式可以获取很大的I/O提升，省去了用户空间到内核空间复制的开销（调用文件的read会把数据先放到内核空间的内存中，然后再复制到用户空间的内存中。）
但也有一个很明显的缺陷——不可靠 写到mmap中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。
Kafka提供了一个参数——producer.type来控制是不是主动flush，如果Kafka写入到mmap之后就立即flush然后再返回Producer叫 同步 (sync)；写入mmap之后立即返回Producer不调用flush叫异步 (async)
传统模式下，当需要对一个文件进行传输的时候，其具体流程细节如下：
基于sendfile实现Zero Copy调用read函数，文件数据被copy到内核缓冲区read函数返回，文件数据从内核缓冲区copy到用户缓冲区write函数调用，将文件数据从用户缓冲区copy到内核与socket相关的缓冲区。数据从socket缓冲区copy到相关协议引擎。以上细节是传统read/write方式进行网络文件传输的方式，我们可以看到，在这个过程当中，文件数据实际上是经过了四次copy操作：
硬盘—>内核buf—>用户buf—>socket相关缓冲区—>协议引擎
而sendfile系统调用则提供了一种减少以上多次copy，提升文件传输性能的方法。
在内核版本2.1中，引入了sendfile系统调用，以简化网络上和两个本地文件之间的数据传输。sendfile的引入不仅减少了数据复制，还减少了上下文切换。
sendfile(socket, file, len);运行流程如下：
sendfile系统调用，文件数据被copy至内核缓冲区再从内核缓冲区copy至内核中socket相关的缓冲区最后再socket相关的缓冲区copy到协议引擎相较传统read/write方式，2.1版本内核引进的sendfile已经减少了内核缓冲区到user缓冲区，再由user缓冲区到socket相关缓冲区的文件copy，而在内核版本2.4之后，文件描述符结果被改变，sendfile实现了更简单的方式，再次减少了一次copy操作。
在Apache、Nginx、lighttpd等web服务器当中，都有一项sendfile相关的配置，使用sendfile可以大幅提升文件传输性能。
Kafka把所有的消息都存放在一个一个的文件中，当消费者需要数据的时候Kafka直接把文件发送给消费者，配合mmap作为文件读写方式，直接把它传给sendfile。
在很多情况下，系统的瓶颈不是CPU或磁盘，而是网络IO，对于需要在广域网上的数据中心之间发送消息的数据流水线尤其如此。进行数据压缩会消耗少量的CPU资源,不过对于kafka而言,网络IO更应该需要考虑。
如果每个消息都压缩，但是压缩率相对很低，所以Kafka使用了批量压缩，即将多个消息一起压缩而不是单个消息压缩Kafka允许使用递归的消息集合，批量的消息可以通过压缩的形式传输并且在日志中也可以保持压缩格式，直到被消费者解压缩Kafka支持多种压缩协议，包括Gzip和Snappy压缩协议