Kafka如何实现高吞吐、低延迟

1.为什么这么快?

kafka为什么这么快,就是kafka再各个层面做了各种各样的优化,尽可能的把资源最大化的利用 

kafka做的优化主要有以下几个方面:

  • 1.Producer批处理
  • 2.PageCache(读写缓存的使用)
  • 3.ZeroCopy
  • 4.Kafka服务端处理请求的方式
  • 5.顺序读写
  • 6.分区机制,以及消费者组的使用
  • 7.消息格式的演变,以及压缩消息
    • 最主要的就是v2版本提取消息公共属性,使用可变长参数的优化
  • 8.摒弃消息的SRC校验(但是损失了安全性,效果有待检验)

本篇接下来的内容就是详细讨论这些方面kafka所做的前三个优化。

2.Producer批处理

首先kafka发送消息不是一条一条发送的,而是攥一批,一批一批的发送的。叫做批量发送。

这样是很大的提高了发送消息的吞吐量的,我们假设发送一条消息的时间是1ms,而此时的吞吐量就是1000TPS。但是假如我们将消息批量发送,1000条消息需要10ms,而此时的吞吐量就达到了1000*100TPS。而且这样也很大程度的减少了请求Broker的次数,提升了总体的效率。

注:批量发送消息的大小是可以在配置文件中配置的,而且还可以进行类似于一个超时时间的配置,超过这个超时时间还没有达到配置文件中的消息大小,也是会发送消息的。

如图为kafka发送消息的一次Producer请求过程,整个过程有两个线程,send用户主线程,和发送消息的Sender线程。Sender线程异步的也是在构造KafkaProducer对象的时候创建的。

用户主线程: 1.消息序列化,计算消息分区。2.追加到对应的缓冲区

Sender线程:2.按照Broker进行分组(Topic+Partition)。2.轮询缓冲区获取到准备就绪的消息,进行分发送。

Kafka如何实现高吞吐、低延迟

3.PageCache

说到PageCache,首先就说下缓存,缓存按照类型分,主要分为两大类只读缓存读写缓存

只读缓存和读写缓存的区别更新数据的时候是否经过缓存。

正常的场景我们对只读缓存的应用比较多,读写缓存的应用极其少,但是消息队列就是其中的应用场景之一,因为有着读与写近似于1:1的比例。

PageCache就是一种典型的读写缓存,是操作系用在内存那种来给文件做的缓存。Kakfa发送消息成功的标志就是只要写入PageCache就认定为成功,具体的入盘操作就交给OS自己去做处理(可以变为同步刷盘,但是不建议使用,性能损耗比较大,而且kafka具有replica的机制,很大程度上保证了消息不会丢失)。

好处:

  1. PageCache 和文件系统的一致性完全交给OS来处理,会比进程内维护更加安全有效。
  2. 对于一个配置比较好的Kafka集群,读写基本都是走的PageCache,基本很少查询磁盘,很大程度上的提供了kafka的效率。

如图为PageCache的基本介绍与操作。

producer发送消息,发送到PageCache之后,Broker就可以返回消息发送成功(要根据Broker端配置的消息发送成功定义来判断)。

consumer拉取消息,命中,直接放回,未命中,从磁盘同步到PageCache,然后返回。

Kafka如何实现高吞吐、低延迟

4.ZeroCopy

Kafka在完成文件网络传输的时候,利用里OS的ZeroCopy极大的提升了,文件网络传输的效率,从而提升了系统的效率。

4.1普通Copy

拿java程序为例子,我们想要从磁盘copy一个文件,往往需要两个步骤:

1.read()

2.write()

但是一次普通的copy在OS中往往没有这么简单,如下图所示,为一次普通copy的时序图:

可以看到进行了四次数据copy,和四次上线文切换

Kafka如何实现高吞吐、低延迟

接下来通过普通copy的流程图来解释一次,copy的具体过程:

如下图所示结合时序图可以看出一共经历四个步骤:

1.掉用read() ,文件A中的内容被复制到了 内核模式中的Read Buffer中。此时用户状态切换到内核状态

2.CPU控制将内核状态数据复制应用(用户)状态下。用户状态 -> 内核状态。

3.调用write()时,将用户状态下的内容复制到内核状态下的 Socket Buffer 中。

4.将Socket Buffer 的数据复制到网卡缓存中去。最后 内核状态 -> 用户状态 ,一次普通copy结束。

Kafka如何实现高吞吐、低延迟

我们可以看出一次普通的copy做了大量的上下文切换,与数据的copy,其实很多都是不必要的。数据的copy是io密集型的操作,而上下文的切换是cpu密集型的操作,尤其是上下文切换带来的系统性能的损耗,是巨大的。因此OS在这些方面开始做了一些优化,减少了不必要的copy次数和不必要的上下文切换的次数,就出现了ZeroCopy

4.2ZeroCopy

**ZeroCopy:**零拷贝是指将数据直接从磁盘文件复制到网卡设备中,而不需要经由应用程序之手。零拷贝技术是通过DMA来实现的。将文件内容copy到内核空间的read Buffer中,不过不需要讲吧数据复制到Socket Buffer中,Socket Buffer仅仅包含了一些文件的描述符号(数据的地址和长度等等)。DMA引擎直接将数据从内核空间传递到网卡设备中去。需要注意的是零拷贝不是不进行copy而是,在内核空间下进行了0次copy。

对于Linux操作系统来言,就是通过**sendfile()系统方法的调用来完成一次零拷贝,对于java语言来说就是通过transferTo()**方法来去调用这个系统调用。

我们知道任何技术的出现都不是一蹴而就的,都是有一个演进过程的,零拷贝也是,经历了普通ZeroCopy到完全体的ZeroCopy的演进。我们相信以后的ZeroCopy可能要不现在的最终形态的零拷贝更加高效。

普通零copy

严格的意义来讲普通的ZeroCopy并不是一个严谨的零拷贝,在内核状态下还是会经过一次copy。

还是先来看下普通零拷贝的时序图:

我们需要注意的是零拷贝并不是不进行

可以和普通的copy进行对比,明显发现流程简介了很多,尤其是上下文切换的次数,减少到了两次,copy次数减少到了三次。

Kafka如何实现高吞吐、低延迟

接下来我们通过流程图来分析一次普通零copy的过程:

1.调用transferTo()方法,用户空间转换为内核空间,将数据从存储copy到 内核空间的read Buffer中。

2.通过Block DMA技术直接将数据从 内核空间的 Read Buffer copy 到 内核空间的 Socket Buffer 中。

3.将数据copy到网卡Buffer中去。内核空间 -> 用户空间。一次普通的零拷贝结束。

Kafka如何实现高吞吐、低延迟

通过对比我们可以看到,一次普通的零copy将 copy的次数减少了一次,上下文切换的次数减少到了两次。已经非常大程度上的提升了一次copy的性能,但是还是没有做到真正意义上的零拷贝,还需要将Read Buffer中的数据copy到Socket Buffer中去。

零拷贝

如下图所示,为一次最终意义上的零拷贝的时序图,怎么样?看起来是不是特别简洁。
整个过程仅仅出现了 两次copy和两次上下文切换。
最终完成了内核空间上数据零拷贝。将数据的拷贝次数和上线文切换的次数都减少到了两次。

Kafka如何实现高吞吐、低延迟

和普通零拷贝对比仅仅是最后一步发生了变化,就是最后一次copy直接将数据从内核空间copy到网卡缓存。而不需要再将数据copy到Socket Buffer中去了。将数据copy到内核空间下的Read Buffer中后,并没有再将数据copy到内核状态下的 socket buffer中去,仅仅是将数据的描述信息发给到了socket buffer中去,最终通过DMA引擎将数据从高内核模式直接传输到网卡设备中去,完成一次零拷贝。

Kafka如何实现高吞吐、低延迟

kafka通过使用 ZeroCopy技术来进一步提升了自己的性能。kafka对OS的使用基本就是无所不用其极呀!!

今天的文章主要讲了kafka为什么这么快的原因,以及对Kafka使用批处理、PageCache、ZeroCopy进行了详细的解释。
下篇文章会对接下来的几种优化,作出详细的分析。

区块链毕设网(www.qklbishe.com)全网最靠谱的原创区块链毕设代做网站
部分资料来自网络,侵权联系删除!
资源收费仅为搬运整理打赏费用,用户自愿支付 !
qklbishe.com区块链毕设代做网专注|以太坊fabric-计算机|java|毕业设计|代做平台 » Kafka如何实现高吞吐、低延迟

提供最优质的资源集合

立即查看 了解详情