Kafka设计（3）效率

参考文档： http://kafka.apache.org/documentation/#design

效率

开发者取得了重大的成就以提升效率。我们的一个主要用例是处理大量的Web活动数据：每一次页面访问可能产生多个写入。我们假设每个已发布的消息被至少一个消费者（通常会更多），因此我们努力让消费尽可能低成本。

基于研发经验和运行大量类似系统，我们同样发现，性能是高效多租户处理的关键。如果下游基础服务因为上游应用的小负载就很容易成为瓶颈，将产生很多问题。通过很高的性能，我们可以帮助上游应用翻转与下游服务的负载。当我们试图在集中式集群中运行支持几十上百个应用集中服务时，这一点尤其重要，因为使用方式可能每天都会改变。

在前文探讨了磁盘效率。虽然消除了糟糕的磁盘访问模式（随机读写），但这种系统还有两种常见低效原因：太多小IO操作和过多的字节拷贝。

小IO

小IO问题在客户端、服务器以及服务器内部持久化操作都可能发生。

为了避免小IO，协议基于消息集抽象构建，其轻易地将消息分组到一起。这允许网络请求将消息组合来减少网络往返的负载而不是每次只发送一个消息。服务器一次性添加多个消息组到日志，客户端一次性获取大量连续的消息组。

这个简单优化实现了数量级的加速。批量处理带来了大量网络包、大量顺序磁盘操作、连续的内存块等，所有这些让Kafka将突发的随机消息写入变成线性写入。

字节拷贝

另一个低效原因是字节拷贝。在很少的消息产生时这不成问题，当负载上来时将带来显著影响。为了避免它，我们在生产者、消费者、经纪人（Kafka broker）间使用相同的标准二进制消息格式，以便在其间的消息传递无需修改数据。

kafka维护的消息日志实际上是一个文件目录，每个日志由顺序消息集组成并以和生产者消费者相同的格式写入到磁盘。维护这个通用格式可以优化最重要的操作：网络传输持久化日志块。现代UNIX操作系统提供了高度优化代码来将页面缓存数据发送到socket;在Linux中使用sendfile系统调用实现。

要想理解sendfile的优势，需要先理解数据从文件传递到socket的一般路径：

1. 操作系统从磁盘读取数据到内核空间的页面缓存
2. 应用从内核空间读取数据到用户空间buffer
3. 应用写入数据到内核空间的socket buffer
4. 操作系统将数据从socket buffer拷贝到NIC（网卡） buffer从而实现网络发送。

以上方式明显很低效，使用了4次拷贝的2次系统调用。使用sendfile，通过操作系统直接将数据从页面缓存发送到网络，避免了多次拷贝。在这种优化路径下，只需要进行最终的拷贝数据到NIC buffer。

我们认为一个消息Topic有多个消费者是常见场景。使用上面的零拷贝优化，数据一次性拷贝到页面缓存在每个消费中多次使用，而不是存储在内存每次读取都需要拷贝到用户空间。这让消息消费速率能够接近网络的上限。

页面缓存和sendfile技术意味着kafka集群在消费者访问时几乎看不到磁盘读取活动，因为消费者读取的数据几乎都从cache中获取。

更多的Java对sendfile和零拷贝的支持，可参考此文章

端到端的批量压缩

在一些场景下，瓶颈不是CPU和磁盘而是网络带宽。当在多个数据中心间通过广域网用数据管道传递消息时很容易产生网络带宽瓶颈。当然，用户不在Kafka的支持下压缩消息，由于同一类型的消息有大量的重复数据（例如：json中的字段名称、Web日志中的user agent、常见的字符串等），自己做压缩只有可怜的压缩率。高效的压缩需要压缩多个消息而不是独立的压缩每个消息。

Kafka有高效批量压缩格式。一批消息可以以这种格式一起压缩和发送到服务器。这批消息会以压缩格式写入，压缩格式存储在日志，只会在消费者端被解压缩。

Kafka支持GZIP、Snappy、LZ4和ZStandard压缩协议。更多压缩细节可以在此找到。