Kafka 为什么快？

前言

本文只想从作者本身的认识来谈谈 kafka 为什么会这么快？
我们都知道 kafka 是基于磁盘的，
但是他的存储和读取速度确是非常的快的。
阅读本文前，你可能需要基本了解 kafka 使用 和 架构。

为什么快？

我们可以从以下几个角度来分析以下：

1. 磁盘的读写速度
2. 数据检索

零拷贝

• 传统的文件读取过程
  当我们将服务器的磁盘文件 读取 发送到 客户端,
  传统的过程大概是这样子：
  1. 操作系统将磁盘数据读取到 Kernel空间 缓存页 ReadBuffer 中。
  2. 应用程序将数据从 缓存页 ReadBuffer 中 拷贝到 应用空间
  3. 应用程序将数据从 Application Buffer 中 写入到 Socket Buffer 套接字中
  4. 操作系统将将数据从 Socket Buffer 再发送到 网卡，进入网络开始传输

传统Copy.png

一般而言，我们这样是没有问题的，
但是如果我们只是将数据完整的发送到网卡，
而不需要对数据做操作，
那么这样做无疑就显得很多余了。
于是我们就会想，
针对这种场景我们是不是可以直接将数据就从磁盘发送到网卡呢？？

• Direct Memory Access
  什么是 DMA（Direct Memory Access） 呢？
  简单来说，
  一种可让某些硬件子系统去直接访问系统主内存，
  而不用依赖CPU的计算机系统的功能。
  也就是说，我们可以从将数据读取到 Kernel空间 缓存页 ReadBuffer，
  然后就可以直接发送到网卡 Buffer了。
  这样就可以大大的加快文件传输的速度了。
  也就是因为 DMA 技术，所以就产生了我们所谓的 Zero Copy 技术。
  而 kafka 使用的场景也正好可以完美的和这种技术切合。

追加写入

这个涉及到磁盘的设计原理...
感兴趣的可以自行百度搜索一下:磁盘读写原理。
这里我们就不多讨论了。
但是根据 LinkedIn 的一个实验数据可以大致了解到，
磁盘的 随机读写 和 顺序读写 是有比较大的差距的，
而 kafka 消息队列的设计，
则是完全基于顺序读写，
所以其速度还是相当可观的。

Memory Mapped Files

以下内容来自掘金
作者：java闸瓦
链接：https://juejin.im/post/5cd2db8951882530b11ee976
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

即便是顺序写入硬盘，硬盘的访问速度还是不可能追上内存。
所以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)。

上面这段话本人是看的有点似懂非懂，
但是大概可以理解为以下两点：

1. kafka写入数据的时候，并不是直接写磁盘。
   而是写入一个内存空间 — mmap，
   然后通过mmap的缓存加快速度。

2. 同是因为是内存，如果服务挂掉，会导致数据丢失，
   如果想避免这种问题，
   客户端需要调用flush，
   对数据进行同步写入。

log index

上面说的都是关于磁盘这块速度的提升，
通过这些方法使得kafka 虽然是基于磁盘，
但是速度已经接近内存，
接下来我们再来看看kafka 数据的检索相关内容。

1. kafka文件是怎么储存的？

• Topic 和 Partition 的储存
  我们可以找到我们 Kafka 存储目录 (log.dirs定义的目录)，
  可以发现该目录下有很多文件夹，
  这些文件夹的命名方式格式是 topic-partition,大概类似：

      helloTopic-0
      helloTopic-1
      helloTopic-2
  

  表示，该kafka 有一个 名为 helloTopic 的 Topci，其有三个分区：0,1,2

  这就是 Kafka 在 topic 和 partition 维度的储存方式了

• Partition 里面的数据储存

  • Segment
    我们进入 一个 partition 的目录，可以发现一些类似下面这样的文件：
    （该文件是我造的，为了方便讲解）

    00000000000000000000.index
    00000000000000000000.log
    00000000000000000010.index
    00000000000000000010.log
    

  我们可以发现，该目录下有两种文件：.index 和 .log。
  同样也可以发现：index 和 log 文件是成对的。
  那么其实kafka 的逻辑是这样的：
  一个 Partition 下会有多个 Segment，
  而一个 Segment 会包含 一个.index文件 和 一个.log文件
  从这些文件来看，
  我们这里就是两个 Segment：
  00000000000000000000 和 00000000000000000010

  看起来Segment的命名好像有点规律可循，
  实际上 Segment的命名 和 他保存的数据是有很大关系的。
  我们都知道，Kafka 消息的保存位置是通过一个 offset 来确定的，
  而这个 Segment 的命名就是其保存的消息的 offset 最小值+1。
  我们这里就是 Segment 00000000000000000000 保存了 offset 1 到 10 的消息
  而 Segment 00000000000000000010 保存了 offset 大于 11 的数据，
  并且 Segment 是可以排序的，所以当一个 请求来了，
  可以很快的通过二分查找定位到数据是在哪个 Segment。

这里额外提一下就是，因为分了 Segment，也方便了Kafka 对于过期数据的清理。

上面看完 Segment,我们来看看 Index 和 log 文件吧

• Index 和 log 文件
  我们上面已经知道 一个Index 和 一个Log 文件就组成了一个 Segment。
  当来了一个消息请求，我们通过 offset快速定位到了 Segment，
  接下来，我们还得根据这个 offset 快速定位到具体消息的位置。
  而我们的 log 文件其实就是存储的具体的消息内容，
  而 index 文件则存储的是 log文件里面的消息的索引。

  说了这么多，我们最后一个列子来看，
  更进一步的了解下：

  1. 假如现在有一个 offset = 11 的消息请求过来了。
  2. 那么首先根据 offset 查找，可以定位到消息在 Segment 00000000000000000010 里面。
  3. 因为index保存的是 log文件的索引，
     所以我们在 Index 里面可以找到第offset - 10 = 1条数据，
     这条数据就会记录该 offset 消息在 log 文件的位置。
  4. 拿到 index 的索引，我们就可以快速找到该消息返回给客户端了

数据压缩

Kafka的数据是支持压缩的，
这也是其快的一个重要方面

消息集

Producer会把消息封装成一个消息集发送给服务端，
而不是单条的消息；
服务端把消息集一次性的追加到日志文件中，
这样批量操作就减少了频繁的 IO操作。
其消息的保存格式是直接使用的二进制，
这也也省略了各种消息协议带来的开销。

本文就分享到这里，如果有错误欢迎指出。

如果觉的本文对你有帮助，欢迎点赞！！谢谢！！