Kafka为什么这么快？ 为何卡夫卡如此迅猛？

Kafka为什么这么快

如果想了解Kafka为什么这么快方面的知识，具体详情如下：

深入地从 IO、线程、数据结构、编码等方面剖析了Redis “快”的内部秘密。

下面不念讲一讲Kafka性能优化方面的知识，不念决定将这篇性能方面的博文作为 Kafka 系列的开篇之作。

先预告一下 Kafka 系列文章，大家敬请期待哦：

以讲解性能作为 Kafka 之旅的开篇之作，让我们一起来深入了解 Kafka “快”的内部秘密。

你不仅可以学习到 Kafka 性能优化的各种手段，也可以提炼出各种性能优化的方法论，这些方法论也可以应用到我们自己的项目之中，助力我们写出高性能的项目。

关公战秦琼

★

同学: Redis 和 Kafka 完全是不同作用的中间件，有比较性吗？

是的，所以此文讲的不是《分布式缓存的选型》，也不是《分布式中间件对比》。我们聚焦于这两个不同领域的项目对性能的优化，看一看优秀项目对性能优化的通用手段，以及在针对不同场景下的特色的优化方式。

很多人学习了很多东西，了解了很多框架，但在遇到实际问题时，却常常会感觉到知识不足。这就是没有将学习到的知识体系化，没有从具体的实现中抽象出可以行之有效的方法论。

学习开源项目很重要的一点就是归纳，将不同项目的优秀实现总结出方法论，然后演绎到自我的实践中去。

Kafka性能全景

从高度抽象的角度来看，性能问题逃不出下面三个方面：

• 网络
• 磁盘
• 复杂度

对于 Kafka 这种网络分布式队列来说，网络和磁盘更是优化的重中之重。

针对于上面提出的抽象问题，解决方案高度抽象出来也很简单：

• 并发
• 压缩
• 批量
• 缓存
• 算法

知道了问题和思路，我们再来看看，在 Kafka 中，有哪些角色，而这些角色就是可以优化的点：

• Producer
• Broker
• Consumer

是的，所有的问题，思路，优化点都已经列出来了，我们可以尽可能的细化，三个方向都可以细化，如此，所有的实现便一目了然，即使不看 Kafka 的实现，我们自己也可以想到一二点可以优化的地方。

这就是思考方式。提出问题>列出问题点>列出优化方法>列出具体可切入的点>tradeoff和细化实现。

现在，你也可以尝试自己想一想优化的点和方法，不用尽善尽美，不用管好不好实现，想一点是一点。

★

同学：不行啊，我很笨，也很懒，你还是直接和我说吧，我白嫖比较行。

顺序写

★

同学：人家 Redis 是基于纯内存的系统，你 kafka 还要读写磁盘，能比？

为什么说写磁盘慢？

我们不能只知道结论，而不知其所以然。要回答这个问题，就得回到在校时我们学的操作系统课程了。

同学还留着课本吗？来，翻到讲磁盘的章节，让我们回顾一下磁盘的运行原理。

★

同学：鬼还留着哦，课程还没上到一半书就没了。要不是考试俺眼神好，估计现在还没毕业。

看经典大图：

完成一次磁盘 IO，需要经过寻道、旋转和数据传输三个步骤。

影响磁盘 IO 性能的因素也就发生在上面三个步骤上，因此主要花费的时间就是：

1. 寻道时间：Tseek 是指将读写磁头移动至正确的磁道上所需要的时间。寻道时间越短，I/O 操作越快，目前磁盘的平均寻道时间一般在 3-15ms。
2. 旋转延迟：Trotation 是指盘片旋转将请求数据所在的扇区移动到读写磁盘下方所需要的时间。旋转延迟取决于磁盘转速，通常用磁盘旋转一周所需时间的 1/2 表示。比如：7200rpm 的磁盘平均旋转延迟大约为 60*1000/7200/2 = 4.17ms，而转速为 15000rpm 的磁盘其平均旋转延迟为 2ms。
3. 数据传输时间：Ttransfer 是指完成传输所请求的数据所需要的时间，它取决于数据传输率，其值等于数据大小除以数据传输率。目前 IDE/ATA 能达到 133MB/s，SATA II 可达到 300MB/s 的接口数据传输率，数据传输时间通常远小于前两部分消耗时间。简单计算时可忽略。

因此，如果在写磁盘的时候省去寻道、旋转可以极大地提高磁盘读写的性能。

Kafka 采用顺序写文件的方式来提高磁盘写入性能。顺序写文件，基本减少了磁盘寻道和旋转的次数。磁头再也不用在磁道上乱舞了，而是一路向前飞速前行。

Kafka 中每个分区是一个有序的，不可变的消息序列，新的消息不断追加到 Partition 的末尾，在 Kafka 中 Partition 只是一个逻辑概念，Kafka 将 Partition 划分为多个 Segment，每个 Segment 对应一个物理文件，Kafka 对 segment 文件追加写，这就是顺序写文件。

★

同学：为什么 Kafka 可以使用追加写的方式呢？

这和 Kafka 的性质有关，我们来看看 Kafka 和 Redis，说白了，Kafka 就是一个Queue，而 Redis 就是一个HashMap。Queue和Map的区别是什么？

Queue是 FIFO 的，数据是有序的；HashMap数据是无序的，是随机读写的。Kafka 的不可变性，有序性使得 Kafka 可以使用追加写的方式写文件。

其实很多符合以上特性的数据系统，都可以采用追加写的方式来优化磁盘性能。典型的有Redis的 AOF 文件，各种数据库的WAL(Write ahead log)机制等等。

★

所以清楚明白自身业务的特点，就可以针对性地做出优化。

零拷贝

★

同学：哈哈，这个我面试被问到过。可惜答得一般般，唉。

什么是零拷贝？

我们从 Kafka 的场景来看，Kafka Consumer 消费存储在 Broker 磁盘的数据，从读取 Broker 磁盘到网络传输给 Consumer，期间涉及哪些系统交互。

Kafka Consumer 从 Broker 消费数据，Broker 读取 Log，就使用了 sendfile。

如果使用传统的 IO 模型，伪代码逻辑就如下所示：

readFile(buffer)
send(buffer)