Kafka 精妙的高性能设计（下篇）

大家好，我是武哥。

 

这是《吃透 MQ 系列》的连载：Kafka 高性能设计的下篇。

在 上一篇文章 中，指出了高性能设计的两个关键维度：计算和 IO，可以将它们理解成「道」。同时给出了 Kafka 高性能设计的全景图，可以理解成「术」。

图 1：Kafka 高性能设计的全景图

这篇文章将继续对存储消息和消费消息的 8 条高性能设计手段，逐个展开分析，废话不多说，开始发车。

 1. 存储消息的性能优化手段  

存储消息属于 Broker 端的核心功能，下面是它所采用的 4 条优化手段。
1、IO 多路复用

 

对于 Kafka Broker 来说，要做到高性能，首先要考虑的是：设计出一个高效的网络通信模型，用来处理它和 Producer 以及 Consumer 之间的消息传递问题。

 

先引用 Kafka 2.8.0 源码里 SocketServer 类中一段很关键的注释：

通过这段注释，其实可以了解到 Kafka 采用的是：很典型的 Reactor 网络通信模型，完整的网络通信层框架图如下所示：

图 2：Kafka 网络通信层的框架图

通俗点记忆就是 1 + N + M：

1：表示 1 个 Acceptor 线程，负责监听新的连接，然后将新连接交给 Processor 线程处理。

N：表示 N 个 Processor 线程，每个 Processor 都有自己的 selector，负责从 socket 中读写数据。

M：表示 M 个 KafkaRequestHandler 业务处理线程，它通过调用 KafkaApis 进行业务处理，然后生成 response，再交由给 Processor 线程。

 

对于 IO 有所研究的同学，应该清楚：Reactor 模式正是采用了很经典的 IO 多路复用技术，它可以复用一个线程去处理大量的 Socket 连接，从而保证高性能。Netty 和 Redis 为什么能做到十万甚至百万并发？它们其实都采用了 Reactor 网络通信模型。

2、磁盘顺序写

通过 IO 多路复用搞定网络通信后，Broker 下一步要考虑的是：如何将消息快速地存储起来？

 

在  Kafka 存储选型的奥秘  一文中提到了：Kafka 选用的是「日志文件」来存储消息，那这种写磁盘文件的方式，又究竟是如何做到高性能的呢？

 

这一切得益于磁盘顺序写，怎么理解呢？

 

Kafka 作为消息队列，本质上就是一个队列，是先进先出的，而且消息一旦生产了就不可变。这种有序性和不可变性使得 Kafka 完全可以「顺序写」日志文件，也就是说，仅仅将消息追加到文件末尾即可。

 

有了顺序写的前提，我们再来看一个对比实验，从下图中可以看到：磁盘顺序写的性能远远高于磁盘随机写，甚至高于内存随机写。

图3：磁盘和内存的 IO 速度对比

原因很简单：对于普通的机械磁盘，如果是随机写入，性能确实极差，也就是随便找到文件的某个位置来写数据。但如果是顺序写入，因为可大大节省磁盘寻道和盘片旋转的时间，因此性能提升了 3 个数量级。

 

3、Page Cache

 

磁盘顺序写已经很快了，但是对比内存顺序写仍然慢了几个数量级，那有没有可能继续优化呢？答案是肯定的。

 

这里 Kafka 用到了 Page Cache 技术，简单理解就是：利用了操作系统本身的缓存技术，在读写磁盘日志文件时，其实操作的都是内存，然后由操作系统决定什么时候将 Page Cache 里的数据真正刷入磁盘。

 

通过下面这个示例图便一目了然。
图4：Kafka 的 Page Cache 原理

 

那 Page Cache 究竟什么时候会发挥最大的威力呢？这又不得不提 Page Cache 所用到的两个经典原理。

 

Page Cache 缓存的是最近会被使用的磁盘数据，利用的是「时间局部性」原理，依据是：最近访问的数据很可能接下来再访问到。而预读到 Page Cache 中的磁盘数据，又利用了「空间局部性」原理，依据是：数据往往是连续访问的。

 

而 Kafka 作为消息队列，消息先是顺序写入，而且立马又会被消费者读取到，无疑非常契合上述两条局部性原理。因此，页缓存可以说是 Kafka 做到高吞吐的重要因素之一。

 

除此之外，页缓存还有一个巨大的优势。用过 Java 的人都知道：如果不用页缓存，而是用 JVM 进程中的缓存，对象的内存开销非常大（通常是真实数据大小的几倍甚至更多），此外还需要进行垃圾回收，GC 所带来的 Stop The World 问题也会带来性能问题。可见，页缓存确实优势明显，而且极大地简化了 Kafka 的代码实现。 

4、分区分段结构

 

磁盘顺序写加上页缓存很好地解决了日志文件的高性能读写问题。但是如果一个 Topic 只对应一个日志文件，显然只能存放在一台 Broker 机器上。

 

当面对海量消息时，单机的存储容量和读写性能肯定有限，这样又引出了又一个精妙的存储设计：对数据进行分区存储。

 

我在 Kafka 架构设计的任督二脉 一文中详细解释了分区（Partition）的概念和作用，它是 Kafka 并发处理的最小粒度，很好地解决了存储的扩展性问题。随着分区数的增加，Kafka 的吞吐量得以进一步提升。

 

其实在 Kafka 的存储底层，在分区之下还有一层：那便是「分段」。简单理解：分区对应的其实是文件夹，分段对应的才是真正的日志文件。

图5：Kafka 的 分区分段存储

每个 Partition 又被分成了多个 Segment，那为什么有了 Partition 之后，还需要 Segment 呢？

如果不引入 Segment，一个 Partition 只对应一个文件，那这个文件会一直增大，势必造成单个 Partition 文件过大，查找和维护不方便。

 

此外，在做历史消息删除时，必然需要将文件前面的内容删除，只有一个文件显然不符合 Kafka 顺序写的思路。而在引入 Segment 后，则只需将旧的 Segment 文件删除即可，保证了每个 Segment 的顺序写。

 

 2. 消费消息的性能优化手段  

Kafka 除了要做到百万 TPS 的写入性能，还要解决高性能的消息读取问题，否则称不上高吞吐。下面再来看看 Kafka 消费消息时所采用的 4 条优化手段。
1、稀疏索引

如何提高读性能，大家很容易想到的是：索引。Kafka 所面临的查询场景其实很简单：能按照 offset 或者 timestamp 查到消息即可。

 

如果采用 B Tree 类的索引结构来实现，每次数据写入时都需要维护索引（属于随机 IO 操作），而且还会引来「页分裂」这种比较耗时的操作。而这些代价对于仅需要实现简单查询要求的 Kafka 来说，显得非常重。所以，B Tree 类的索引并不适用于 Kafka。

 

相反，哈希索引看起来却非常合适。为了加快读操作，如果只需要在内存中维护一个「从 offset 到日志文件偏移量」的映射关系即可，每次根据 offset 查找消息时，从哈希表中得到偏移量，再去读文件即可。（根据 timestamp 查消息也可以采用同样的思路）

 

但是哈希索引常驻内存，显然没法处理数据量很大的情况，Kafka 每秒可能会有高达几百万的消息写入，一定会将内存撑爆。

 

可我们发现消息的 offset 完全可以设计成有序的（实际上是一个单调递增 long 类型的字段），这样消息在日志文件中本身就是有序存放的了，我们便没必要为每个消息建 hash 索引了，完全可以将消息划分成若干个 block，只索引每个 block 第一条消息的 offset 即可，先根据大小关系找到 block，然后在 block 中顺序搜索，这便是 Kafka “稀疏索引” 的设计思想。

图6：Kafka 的稀疏索引设计

 

采用 “稀疏索引”，可以认为是在磁盘空间、内存空间、查找性能等多方面的一个折中。有了稀疏索引，当给定一个 offset 时，Kafka 采用的是二分查找来高效定位不大于 offset 的物理位移，然后找到目标消息。

2、mmap

利用稀疏索引，已经基本解决了高效查询的问题，但是这个过程中仍然有进一步的优化空间，那便是通过 mmap（memory mapped files） 读写上面提到的稀疏索引文件，进一步提高查询消息的速度。

注意：mmap 和 page cache 是两个概念，网上很多资料把它们混淆在一起。此外，还有资料谈到 Kafka 在读 log 文件时也用到了 mmap，通过对 2.8.0 版本的源码分析，这个信息也是错误的，其实只有索引文件的读写才用到了 mmap.

 

究竟如何理解 mmap？前面提到，常规的文件操作为了提高读写性能，使用了 Page Cache 机制，但是由于页缓存处在内核空间中，不能被用户进程直接寻址，所以读文件时还需要通过系统调用，将页缓存中的数据再次拷贝到用户空间中。

 

而采用 mmap 后，它将磁盘文件与进程虚拟地址做了映射，并不会招致系统调用，以及额外的内存 copy 开销，从而提高了文件读取效率。

图7：mmap 示意图，引自《码农的荒岛求生》

 

关于 mmap，好友小风哥写过一篇很通俗的文章： mmap 可以让程序员解锁哪些骚操作？大家可以参考。

具体到 Kafka 的源码层面，就是基于 JDK nio 包下的 MappedByteBuffer 的 map 函数，将磁盘文件映射到内存中。

至于为什么 log 文件不采用 mmap？其实是一个特别好的问题，这个问题社区并没有给出官方答案，网上的答案只能揣测作者的意图。个人比较认同 stackoverflow 上的这个答案：

mmap 有多少字节可以映射到内存中与地址空间有关，32 位的体系结构只能处理 4GB 甚至更小的文件。Kafka 日志通常足够大，可能一次只能映射部分，因此读取它们将变得非常复杂。然而，索引文件是稀疏的，它们相对较小。将它们映射到内存中可以加快查找过程，这是内存映射文件提供的主要好处。

 

3、零拷贝

消息借助稀疏索引被查询到后，下一步便是：将消息从磁盘文件中读出来，然后通过网卡发给消费者，那这一步又可以怎么优化呢？

 

Kafka 用到了零拷贝（Zero-Copy）技术来提升性能。所谓的零拷贝是指数据直接从磁盘文件复制到网卡设备，而无需经过应用程序，减少了内核和用户模式之间的上下文切换。

 

下面这个过程是不采用零拷贝技术时，从磁盘中读取文件然后通过网卡发送出去的流程，可以看到：经历了 4 次拷贝，4 次上下文切换。

图8：非零拷贝技术的流程图，引自《艾小仙》

 

如果采用零拷贝技术（底层通过 sendfile 方法实现），流程将变成下面这样。可以看到：只需 3 次拷贝以及 2 次上下文切换，显然性能更高。

图9：零拷贝技术的流程图，引自《艾小仙》

 

4、批量拉取

和生产者批量发送消息类似，消息者也是批量拉取消息的，每次拉取一个消息集合，从而大大减少了网络传输的 overhead。

 

另外，在 Kafka 精妙的高性能设计（上篇） 中介绍过，生产者其实在 Client 端对批量消息进行了压缩，这批消息持久化到 Broker 时，仍然保持的是压缩状态，最终在 Consumer 端再做解压缩操作。

 

3. 写在最后  

以上就是 Kafka 12 条高性能设计手段的详解，这两篇文章先从 IO 和计算两个维度进行宏观上的切入，然后顺着 MQ 一发一存一消费的脉络，从微观上解构了 Kafka 高性能的全景图。

 

可以说 Kafka 在高性能设计方面是教科书般的存在，它从 Prodcuer 、到 Broker、再到 Consumer，在掏空心思地优化每一个细节，最终才做到了单机每秒几十万 TPS 的极致性能。

 

最后，希望本文的分析技巧可以帮助你吃透其他高性能的中间件。我是武哥，我们下期见！

 

 

公众号：铭毅天下Elasticsearch