kafka高吞吐、低延时、高性能的实现原理_kafka吞吐量

作者：源码时代-Raymon老师

Kafka的高吞吐、低延时、高性能的实现原理

Kafka是大数据领域无处不在的消息中间件，目前广泛使用在企业内部的实时数据管道，并帮助企业构建自己的流计算应用程序。Kafka虽然是基于磁盘做的数据存储，但却具有高性能、高吞吐、低延时的特点，其吞吐量动辄几万、几十上百万，这其中的原由值得我们一探究竟，让我们一起掌握Kafka各种精巧的设计。

吞吐量：吞吐量是指在一定时间内通过系统、网络或设备传输的数据量或处理的事务数量。它是衡量系统性能和效率的重要指标之一。

• 对于网络，吞吐量可以指网络连接的数据传输速率，单位可以是字节/秒或比特/秒
• 对于服务器或数据库系统，吞吐量可以表示系统每秒能够处理的事务或请求的数量
• 在存储系统中，吞吐量可以表示系统每秒读取或写入的数据量。

较高的吞吐量意味着系统能够更快地处理数据，而较低的吞吐量可能导致数据传输延迟和系统繁忙。

kafka，每毫秒可以处理1条数据，每秒可以处理1000条数据，这个单位时间内可以处理多少条数据，就叫做吞吐量，1000条数据，每条数据10kb，吞吐量相当于是每秒处理大概10mb的数据

低延迟：低延迟是指系统或应用在处理请求或传输数据时所需的时间尽可能地短。

如果来一条数据就处理一条数据，可能会导致每条数据要处理假设1毫秒，那么此时每秒可以处理1000条数据，这就是每秒的吞吐量，但是如果采用微批处理技术呢？比如说把10毫秒内的数据收集起来一共有1000条数据，接着一次性交给引擎来处理，1毫秒就把1000条数据给处理完了。那么1秒内就可以处理10万条数据，吞吐量直接提升100倍。

这个就是所谓的流式计算采用的微批处理技术，你一条一条处理，每条数据都需要启动新的计算资源，有网络开销，甚至是磁盘开销。但是你一次性处理1000条，跟你一次性处理1条其实是差不多的。

接下来我们看看Kafka的高吞吐以及低延时实现的底层原理是什么。

1、页缓存技术 + 磁盘顺序写

首先Kafka每次接收到数据都会往磁盘上去写，如下图所示：

如果把数据基于磁盘来存储，频繁的往磁盘文件里写数据，这个性能会不会很差？大家肯定都觉得磁盘写性能是极差的。

但是实际上Kafka在这里有极为优秀和出色的设计，就是为了保证数据写入性能，首先Kafka是基于操作系统的页缓存来实现文件写入的。（操作系统本身有一层缓存，叫做page cache，是在内存里的缓存，我们也可以称之为os cache，意思就是操作系统自己管理的缓存。）

在写入磁盘文件的时候，可以直接写入这个os cache里，也就是仅仅写入内存中，接下来由操作系统自己决定什么时候把os cache里的数据真的刷入磁盘文件中。
仅仅这一个步骤，就可以将磁盘文件写性能提升很多了，因为这里相当于是在写内存，不是在写磁盘，大家看下图：

光有页缓存这一点已经可以提升很多性能了，但是kafka在这里还使用到一个磁盘顺序写的技术，也就是说，仅仅将数据追加到文件的末尾，不是在文件的随机位置来修改数据。

对于一块硬盘，它有几个重要指标：顺序读写能力和随机读写能力. 若把硬盘比作一个仓库，硬盘中的数据比作仓库中各种各样的货物. 硬盘的读写比作仓库中一个工人的进货和出货. 这时如果一个工人需要取一个大电冰箱，虽然冰箱很大很重，但是工人却能很快完成，这就是顺序读写.

但如果一个工作需要同时取一瓶水，一个文具盒、一包面包、一个鼠标、一管牙膏等，虽然它们很小很轻，但工作必须跑遍整个仓库才能拿到它们. 因此，工人往往会做的更慢，这就是随机读写.

小结：
页缓存+磁盘顺序写的方式让kafka的写性能极高，最大程度减少了每条数据处理的时间开销，反过来就大幅度提升了每秒处理数据的吞吐量，一般kafka部署在物理机上，单机每秒写入几万到几十万条消息是没问题的。
这种方式同时也兼顾了低延迟和高吞吐两个要求，尽量把每条消息的写入性能压榨到极致，就可以实现低延迟的写入，同时对应的每秒的吞吐量自然就提升了，这也是kafka非常核心的一个底层机制。

2、零拷贝实现高性能读取

那么在消费数据的时候，需要从磁盘文件里读取数据后通过网络发送出去，这个时候怎么提升性能呢？
首先就是利用了page cache技术，之前说过，kafka写入数据到磁盘文件的时候，实际上是写入page cache的，没有直接发生磁盘IO，所以写入的数据大部分都是停留在os层的page cache里的（这个本质其实跟elasticsearch的实现原理是类似的）

然后在读取的时候，如果正常情况下从磁盘读取数据，先尝试从page cache读，读不到才从磁盘IO读，读到数据以后先会放在os层的一个page cache里，接着会发生上下文切换到系统那边，把os的读缓存数据拷贝到应用缓存里。

接着再次发生上下文切换到os层，把应用缓存的数据拷贝到os的socket缓存中，最后数据再发送到网卡上：【非零拷贝的实现方案】

这个过程里，发生了好几次上下文切换，而且还涉及到了好几次数据拷贝，如果不考虑跟硬件之间的交互，起码是从os cache到用户缓存，从用户缓存到socket缓存，有两次拷贝是绝对没必要的。

但是如果用零拷贝技术，就是linux的sendfile，就可以直接把操作交给os，os看page cache里是否有数据，如果没有就从磁盘上读取，如果有的话直接把os cache里的数据拷贝给网卡了，中间不用走那么多步骤了：【零拷贝技术】

跟上图一对比是不是零拷贝技术就快多了？所以呢，通过零拷贝技术来读取磁盘上的数据，还有page cahce的帮助，这个性能就非常高了。