![](/wp-content/uploads/2023/06/frc-cf0d92129138e2c138e143696168013a.png)
1 前言
相信各位小伙伴之前或多或少接触过消息队列,比较知名的包含Rocket MQ和Kafka,在京东内部使用的是自研的消息中间件JMQ,从JMQ2升级到JMQ4的也是带来了性能上的明显提升,并且JMQ4的底层也是参考Kafka去做的设计。在这里我会给大家展示Kafka它的高性能是如何设计的,大家也可以学习相关方法论将其利用在实际项目中,也许下一个顶级项目就在各位的代码中产生了。
2 如何理解高性能设计
2.1 高性能设计的”秘籍”
先抛开kafka,咱们先来谈论一下高性能设计的本质,在这里借用一下网上的一张总结高性能的思维导图:
从中可以看到,高性能设计的手段还是非常多,从”微观设计”上的无锁化、序列化,到”宏观设计”上的缓存、存储等,可以说是五花八门,令人眼花缭乱。但是在我看来本质就两点:计算和IO。下面将从这两点来浅析一下我认为的高性能的”道”。
2.2 高性能设计的”道法”
2.2.1 计算上的”道”
计算上的优化手段无外乎两种方式:1.减少计算量 2.加快单位时间的计算量
- 减少计算量:比如用索引来取代全局扫描、用同步代替异步、通过限流来减少请求处理量、采用更高效的数据结构和算法等。(举例:mysql的BTree,redis的跳表等)
- 加快单位时间的计算量:可以利用CPU多核的特性,比如用多线程代替单线程、用集群代替单机等。(举例:多线程编程、分治计算等)
2.2.2 IO上的”道”
IO上的优化手段也可以从两个方面来体现:1.减少IO次数或者IO数据量 2.加快IO速度
- 减少IO次数或者IO数据量:比如借助系统缓存或者外部缓存、通过零拷贝技术减少 IO 复制次数、批量读写、数据压缩等。
- 加快IO速度:比如用磁盘顺序写代替随机写、用 NIO 代替 BIO、用性能更好的 SSD 代替机械硬盘等。
3 kafka高性能设计
理解了高性能设计的手段和本质之后,我们再来看看kafka里面使用到的性能优化方法。各类消息中间件的本质都是一个生产者-消费者模型,生产者发送消息给服务端进行暂存,消费者从服务端获取消息进行消费。也就是说kafka分为三个部分:生产者-服务端-消费者,我们可以按照这三个来分别归纳一下其关于性能优化的手段,这些手段也会涵盖在我们之前梳理的脑图里面。
3.1 生产者的高性能设计
3.1.1 批量发送消息
之前在上面说过,高性能的”道”在于计算和IO上,咱们先来看看在IO上kafka是如何做设计的。
IO上的优化
kafka是一个消息中间件,数据的载体就是消息,如何将消息高效的进行传递和持久化是kafka高性能设计的一个重点。基于此分析kafka肯定是IO密集型应用,producer需要通过网络IO将消息传递给broker,broker需要通过磁盘IO将消息持久化,consumer需要通过网络IO将消息从broker上拉取消费。
- 网络IO上的优化:producer->broker发送消息不是一条一条发送的,kafka模式会有个消息发送延迟机制,会将一批消息进行聚合,一口气打包发送给broker,这样就成功减少了IO的次数。除了传输消息本身以外,还要传输非常多的网络协议本身的一些内容(称为Overhead),所以将多条消息合并到一起传输,可有效减少网络传输的Overhead,进而提高了传输效率。
- 磁盘IO上的优化:大家知道磁盘和内存的存储速度是不同的,在磁盘上操作的速度是远低于内存,但是在成本上内存是高于磁盘。kafka是面向大数据量的消息中间件,也就是说需要将大批量的数据持久化,这些数据放在内存上也是不现实。那kafka是怎么在磁盘IO上进行优化的呢?在这里我先直接给出方法,具体细节在后文中解释(它是借助于一种磁盘顺序写的机制来提升写入速度)。
3.1.2 负载均衡
1.kafka负载均衡设计
Kafka有主题(Topic)概念,他是承载真实数据的逻辑容器,主题之下还分为若干个分区,Kafka消息组织方式实际上是三级结构:主题-分区-消息。主题下的每条消息只会在某一个分区中,而不会在多个分区中被保存多份。
Kafka这样设计,使用分区的作用就是提供负载均衡的能力,对数据进行分区的主要目的就是为了实现系统的高伸缩性(Scalability)。不同的分区能够放在不同的节点的机器上,而数据的读写操作也都是针对分区这个粒度进行的,每个节点的机器都能独立地执行各自分区读写请求。我们还可以通过增加节点来提升整体系统的吞吐量。Kafka的分区设计,还可以实现业务级别的消息顺序的问题。
2.具体分区策略
- 所谓的分区策略是指决定生产者将消息发送到那个分区的算法。Kafka提供了默认的分区策略是轮询,同时kafka也支持用户自己制定。
- 轮询策略:也称为Round-robin策略,即顺序分配。轮询的优点是有着优秀的负载均衡的表现。
- 随机策略:虽然也是追求负载均衡,但总体表现差于轮询。
- 消息键划分策略:还要一种是为每条消息配置一个key,按消息的key来存。Kafka允许为每条消息指定一个key。一旦指定了key ,那么会对key进行hash计算,将相同的key存入相同的分区中,而且每个分区下的消息都是有序的。key的作用很大,可以是一个有着明确业务含义的字符串,也可以是用来表征消息的元数据。
- 其他的分区策略:基于地理位置的分区。可以从所有分区中找出那些 Leader 副本在某个地理位置所有分区,然后随机挑选一个进行消息发送。
3.1.3 异步发送
1.线程模型
之前已经说了kafka是选择批量发送消息来提升整体的IO性能,具体流程是kafka生产者使用批处理试图在内存中积累数据,主线程将多条消息通过一个ProduceRequest请求批量发送出去,发送的消息暂存在一个队列(RecordAccumulator)中,再由sender线程去获取一批数据或者不超过某个延迟时间内的数据发送给broker进行持久化。
优点:
- 可以提升kafka整体的吞吐量,减少网络IO的次数;
- 提高数据压缩效率(一般压缩算法都是数据量越大越能接近预期的压缩效果);
缺点:
- 数据发送有一定延迟,但是这个延迟可以由业务因素来自行设置。
3.1.4 高效序列化
1.序列化的优势
Kafka 消息中的 Key 和 Value,都支持自定义类型,只需要提供相应的序列化和反序列化器即可。因此,用户可以根据实际情况选用快速且紧凑的序列化方式(比如 ProtoBuf、Avro)来减少实际的网络传输量以及磁盘存储量,进一步提高吞吐量。
2.内置的序列化器
- org.apache.kafka.common.serialization.StringSerializer;
- org.apache.kafka.common.serialization.LongSerializer;
- org.apache.kafka.common.serialization.IntegerSerializer;
- org.apache.kafka.common.serialization.ShortSerializer;
- org.apache.kafka.common.serialization.FloatSerializer;
- org.apache.kafka.common.serialization.DoubleSerializer;
- org.apache.kafka.common.serialization.BytesSerializer;
- org.apache.kafka.common.serialization.ByteBufferSerializer;
- org.apache.kafka.common.serialization.ByteArraySerializer;
3.1.5 消息压缩
1.压缩的目的
压缩秉承了用时间换空间的经典trade-off思想,即用CPU的时间去换取磁盘空间或网络I/O传输量,Kafka的压缩算法也是出于这种目的。并且通常是:数据量越大,压缩效果才会越好。
因为有了批量发送这个前期,从而使得 Kafka 的消息压缩机制能真正发挥出它的威力(压缩的本质取决于多消息的重复性)。对比压缩单条消息,同时对多条消息进行压缩,能大幅减少数据量,从而更大程度提高网络传输率。
2.压缩的方法
想了解kafka消息压缩的设计,就需要先了解kafka消息的格式:
- Kafka的消息层次分为:消息集合(message set)和消息(message);一个消息集合中包含若干条日志项(record item),而日志项才是真正封装消息的地方。
- Kafka底层的消息日志由一系列消息集合-日志项组成。Kafka通常不会直接操作具体的一条条消息,他总是在消息集合这个层面上进行写入操作。
每条消息都含有自己的元数据信息,kafka会将一批消息相同的元数据信息给提升到外层的消息集合里面,然后再对整个消息集合来进行压缩。批量消息在持久化到 Broker 中的磁盘时,仍然保持的是压缩状态,最终是在 Consumer 端做了解压缩操作。
压缩算法效率对比
Kafka 共支持四种主要的压缩类型:Gzip、Snappy、Lz4 和 Zstd,具体效率对比如下:
3.2 服务端的高性能设计
3.2.1 Reactor网络通信模型
kafka相比其他消息中间件最出彩的地方在于他的高吞吐量,那么对于服务端来说每秒的请求压力将会巨大,需要有一个优秀的网络通信机制来处理海量的请求。如果 IO 有所研究的同学,应该清楚:Reactor 模式正是采用了很经典的 IO 多路复用技术,它可以复用一个线程去处理大量的 Socket 连接,从而保证高性能。Netty 和 Redis 为什么能做到十万甚至百万并发?它们其实都采用了 Reactor 网络通信模型。
1.kafka网络通信层架构
从图中可以看出,SocketServer和KafkaRequestHandlerPool是其中最重要的两个组件:
- SocketServer:主要实现了 Reactor 模式,用于处理外部多个 Clients(这里的 Clients 指的是广义的 Clients,可能包含 Producer、Consumer 或其他 Broker)的并发请求,并负责将处理结果封装进 Response 中,返还给 Clients
- KafkaRequestHandlerPool:Reactor模式中的Worker线程池,里面定义了多个工作线程,用于处理实际的I/O请求逻辑。
2.请求流程
- Clients 或其他 Broker 通过 Selector 机制发起创建连接请求。(NIO的机制,使用epoll)
- Processor 线程接收请求,并将其转换成可处理的 Request 对象。
- Processor 线程将 Request 对象放入共享的RequestChannel的 Request 队列。
- KafkaRequestHandler 线程从 Request 队列中取出待处理请求,并进行处理。
- KafkaRequestHandler 线程将 Response 放回到对应 Processor 线程的 Response 队列。
- Processor 线程发送 Response 给 Request 发送方。
3.2.2 Kafka的底层日志结构
基本结构的展示
Kafka是一个Pub-Sub的消息系统,无论是发布还是订阅,都须指定Topic。Topic只是一个逻辑的概念。每个Topic都包含一个或多个Partition,不同Partition可位于不同节点。同时Partition在物理上对应一个本地文件夹(也就是个日志对象Log),每个Partition包含一个或多个Segment,每个Segment包含一个数据文件和多个与之对应的索引文件。在逻辑上,可以把一个Partition当作一个非常长的数组,可通过这个“数组”的索引(offset)去访问其数据。
2.Partition的并行处理能力
- 一方面,topic是由多个partion组成,Producer发送消息到topic是有个负载均衡机制,基本上会将消息平均分配到每个partion里面,同时consumer里面会有个consumer group的概念,也就是说它会以组为单位来消费一个topic内的消息,一个consumer group内包含多个consumer,每个consumer消费topic内不同的partion,这样通过多partion提高了消息的接收和处理能力
- 另一方面,由于不同Partition可位于不同机器,因此可以充分利用集群优势,实现机器间的并行处理。并且Partition在物理上对应一个文件夹,即使多个Partition位于同一个节点,也可通过配置让同一节点上的不同Partition置于不同的disk drive上,从而实现磁盘间的并行处理,充分发挥多磁盘的优势。
3.过期消息的清除
- Kafka的整个设计中,Partition相当于一个非常长的数组,而Broker接收到的所有消息顺序写入这个大数组中。同时Consumer通过Offset顺序消费这些数据,并且不删除已经消费的数据,从而避免了随机写磁盘的过程。
- 由于磁盘有限,不可能保存所有数据,实际上作为消息系统Kafka也没必要保存所有数据,需要删除旧的数据。而这个删除过程,并非通过使用“读-写”模式去修改文件,而是将Partition分为多个Segment,每个Segment对应一个物理文件,通过删除整个文件的方式去删除Partition内的数据。这种方式清除旧数据的方式,也避免了对文件的随机写操作。
3.2.3 朴实高效的索引
1.稀疏索引
可以从上面看到,一个segment包含一个.log后缀的文件和多个index后缀的文件。那么这些文件具体作用是干啥的呢?并且这些文件除了后缀不同文件名都是相同,为什么这么设计?
- .log文件:具体存储消息的日志文件
- .index文件:位移索引文件,可根据消息的位移值快速地从查询到消息的物理文件位置
- .timeindex文件:时间戳索引文件,可根据时间戳查找到对应的位移信息
- .txnindex文件:已中止事物索引文件
除了.log是实际存储消息的文件以外,其他的几个文件都是索引文件。索引本身设计的原来是一种空间换时间的概念,在这里kafka是为了加速查询所使用。kafka索引不会为每一条消息建立索引关系,这个也很好理解,毕竟对一条消息建立索引的成本还是比较大的,所以它是一种稀疏索引的概念,就好比我们常见的跳表,都是一种稀疏索引。
kafka日志的文件名一般都是该segment写入的第一条消息的起始位移值baseOffset,比如000000000123.log,这里面的123就是baseOffset,具体索引文件里面纪录的数据是相对于起始位移的相对位移值relativeOffset,baseOffset与relativeOffse的加和即为实际消息的索引值。假设一个索引文件为:00000000000000000100.index,那么起始位移值即 100,当存储位移为 150 的消息索引时,在索引文件中的相对位移则为 150 – 100 = 50,这么做的好处是使用 4 字节保存位移即可,可以节省非常多的磁盘空间。(ps:kafka真的是极致的压缩了数据存储的空间)
2.优化的二分查找算法
kafka没有使用我们熟知的跳表或者B+Tree结构来设计索引,而是使用了一种更为简单且高效的查找算法:二分查找。但是相对于传统的二分查找,kafka将其进行了部分优化,个人觉得设计的非常巧妙,在这里我会进行详述。
在这之前,我先补充一下kafka索引文件的构成:每个索引文件包含若干条索引项。不同索引文件的索引项的大小不同,比如offsetIndex索引项大小是8B,timeIndex索引项的大小是12B。
这里以offsetIndex为例子来详述kafka的二分查找算法:
1)普通二分查找
offsetIndex每个索引项大小是8B,但操作系统访问内存时的最小单元是页,一般是4KB,即4096B,会包含了512个索引项。而找出在索引中的指定偏移量,对于操作系统访问内存时则变成了找出指定偏移量所在的页。假设索引的大小有13个页,如下图所示:
由于Kafka读取消息,一般都是读取最新的偏移量,所以要查询的页就集中在尾部,即第12号页上。根据二分查找,将依次访问6、9、11、12号页。
当随着Kafka接收消息的增加,索引文件也会增加至第13号页,这时根据二分查找,将依次访问7、10、12、13号页。
可以看出访问的页和上一次的页完全不同。之前在只有12号页的时候,Kafak读取索引时会频繁访问6、9、11、12号页,而由于Kafka使用了mmap来提高速度,即读写操作都将通过操作系统的page cache,所以6、9、11、12号页会被缓存到page cache中,避免磁盘加载。但是当增至13号页时,则需要访问7、10、12、13号页,而由于7、10号页长时间没有被访问(现代操作系统都是使用LRU或其变体来管理page cache),很可能已经不在page cache中了,那么就会造成缺页中断(线程被阻塞等待从磁盘加载没有被缓存到page cache的数据)。在Kafka的官方测试中,这种情况会造成几毫秒至1秒的延迟。
2)kafka优化的二分查找
Kafka对二分查找进行了改进。既然一般读取数据集中在索引的尾部。那么将索引中最后的8192B(8KB)划分为“热区”(刚好缓存两页数据),其余部分划分为“冷区”,分别进行二分查找。这样做的好处是,在频繁查询尾部的情况下,尾部的页基本都能在page cahce中,从而避免缺页中断。
下面我们还是用之前的例子来看下。由于每个页最多包含512个索引项,而最后的1024个索引项所在页会被认为是热区。那么当12号页未满时,则10、11、12会被判定是热区;而当12号页刚好满了的时候,则11、12被判定为热区;当增至13号页且未满时,11、12、13被判定为热区。假设我们读取的是最新的消息,则在热区中进行二分查找的情况如下:
当12号页未满时,依次访问11、12号页,当12号页满时,访问页的情况相同。当13号页出现的时候,依次访问12、13号页,不会出现访问长时间未访问的页,则能有效避免缺页中断。
3.mmap的使用
利用稀疏索引,已经基本解决了高效查询的问题,但是这个过程中仍然有进一步的优化空间,那便是通过 mmap(memory mapped files) 读写上面提到的稀疏索引文件,进一步提高查询消息的速度。
究竟如何理解 mmap?前面提到,常规的文件操作为了提高读写性能,使用了 Page Cache 机制,但是由于页缓存处在内核空间中,不能被用户进程直接寻址,所以读文件时还需要通过系统调用,将页缓存中的数据再次拷贝到用户空间中。
1)常规文件读写
- app拿着inode查找读取文件
- address_space中存储了inode和该文件对应页面缓存的映射关系
- 页面缓存缺失,引发缺页异常
- 通过inode找到磁盘地址,将文件信息读取并填充到页面缓存
- 页面缓存处于内核态,无法直接被app读取到,因此要先拷贝到用户空间缓冲区,此处发生内核态和用户态的切换
tips:这一过程实际上发生了四次数据拷贝。首先通过系统调用将文件数据读入到内核态Buffer(DMA拷贝),然后应用程序将内存态Buffer数据读入到用户态Buffer(CPU拷贝),接着用户程序通过Socket发送数据时将用户态Buffer数据拷贝到内核态Buffer(CPU拷贝),最后通过DMA拷贝将数据拷贝到NIC Buffer。同时,还伴随着四次上下文切换。
2)mmap读写模式
- 调用内核函数mmap(),在页表(类比虚拟内存PTE)中建立了文件地址和虚拟地址空间中用户空间的映射关系
- 读操作引发缺页异常,通过inode找到磁盘地址,将文件内容拷贝到用户空间,此处不涉及内核态和用户态的切换
tips:采用 mmap 后,它将磁盘文件与进程虚拟地址做了映射,并不会招致系统调用,以及额外的内存 copy 开销,从而提高了文件读取效率。具体到 Kafka 的源码层面,就是基于 JDK nio 包下的 MappedByteBuffer 的 map 函数,将磁盘文件映射到内存中。只有索引文件的读写才用到了 mmap。
3.2.4 消息存储-磁盘顺序写
对于我们常用的机械硬盘,其读取数据分3步:
- 寻道;
- 寻找扇区;
- 读取数据;
前两个,即寻找数据位置的过程为机械运动。我们常说硬盘比内存慢,主要原因是这两个过程在拖后腿。不过,硬盘比内存慢是绝对的吗?其实不然,如果我们能通过顺序读写减少寻找数据位置时读写磁头的移动距离,硬盘的速度还是相当可观的。一般来讲,IO速度层面,内存顺序IO > 磁盘顺序IO > 内存随机IO > 磁盘随机IO。这里用一张网上的图来对比一下相关IO性能:
Kafka在顺序IO上的设计分两方面看:
- LogSegment创建时,一口气申请LogSegment最大size的磁盘空间,这样一个文件内部尽可能分布在一个连续的磁盘空间内;
- .log文件也好,.index和.timeindex也罢,在设计上都是只追加写入,不做更新操作,这样避免了随机IO的场景;
3.2.5 Page Cache的使用
为了优化读写性能,Kafka利用了操作系统本身的Page Cache,就是利用操作系统自身的内存而不是JVM空间内存。这样做的好处有:
- 避免Object消耗:如果是使用 Java 堆,Java对象的内存消耗比较大,通常是所存储数据的两倍甚至更多。
- 避免GC问题:随着JVM中数据不断增多,垃圾回收将会变得复杂与缓慢,使用系统缓存就不会存在GC问题
相比于使用JVM或in-memory cache等数据结构,利用操作系统的Page Cache更加简单可靠。
- 首先,操作系统层面的缓存利用率会更高,因为存储的都是紧凑的字节结构而不是独立的对象。
- 其次,操作系统本身也对于Page Cache做了大量优化,提供了 write-behind、read-ahead以及flush等多种机制。
- 再者,即使服务进程重启,JVM内的Cache会失效,Page Cache依然可用,避免了in-process cache重建缓存的过程。
通过操作系统的Page Cache,Kafka的读写操作基本上是基于内存的,读写速度得到了极大的提升。
3.3 消费端的高性能设计
3.3.1 批量消费
生产者是批量发送消息,消息者也是批量拉取消息的,每次拉取一个消息batch,从而大大减少了网络传输的 overhead。在这里kafka是通过fetch.min.bytes参数来控制每次拉取的数据大小。默认是 1 字节,表示只要 Kafka Broker 端积攒了 1 字节的数据,就可以返回给 Consumer 端,这实在是太小了。我们还是让 Broker 端一次性多返回点数据吧。
并且,在生产者高性能设计目录里面也说过,生产者其实在 Client 端对批量消息进行了压缩,这批消息持久化到 Broker 时,仍然保持的是压缩状态,最终在 Consumer 端再做解压缩操作。
3.3.2 零拷贝-磁盘消息文件的读取
1.zero-copy定义
零拷贝并不是不需要拷贝,而是减少不必要的拷贝次数。通常是说在IO读写过程中。
零拷贝字面上的意思包括两个,“零”和“拷贝”:
- “拷贝”:就是指数据从一个存储区域转移到另一个存储区域。
- “零” :表示次数为0,它表示拷贝数据的次数为0。
实际上,零拷贝是有广义和狭义之分,目前我们通常听到的零拷贝,包括上面这个定义减少不必要的拷贝次数都是广义上的零拷贝。其实了解到这点就足够了。
我们知道,减少不必要的拷贝次数,就是为了提高效率。那零拷贝之前,是怎样的呢?
2.传统IO的流程
做服务端开发的小伙伴,文件下载功能应该实现过不少了吧。如果你实现的是一个web程序 ,前端请求过来,服务端的任务就是:将服务端主机磁盘中的文件从已连接的socket发出去。关键实现代码如下:
while((n = read(diskfd, buf, BUF_SIZE)) > 0)
write(sockfd, buf , n);
传统的IO流程,包括read和write的过程。
- read:把数据从磁盘读取到内核缓冲区,再拷贝到用户缓冲区
- write:先把数据写入到socket缓冲区,最后写入网卡设备
流程图如下:
- 用户应用进程调用read函数,向操作系统发起IO调用,上下文从用户态转为内核态(切换1)
- DMA控制器把数据从磁盘中,读取到内核缓冲区。
- CPU把内核缓冲区数据,拷贝到用户应用缓冲区,上下文从内核态转为用户态(切换2) ,read函数返回
- 用户应用进程通过write函数,发起IO调用,上下文从用户态转为内核态(切换3)
- CPU将用户缓冲区中的数据,拷贝到socket缓冲区
- DMA控制器把数据从socket缓冲区,拷贝到网卡设备,上下文从内核态切换回用户态(切换4) ,write函数返回
从流程图可以看出,传统IO的读写流程 ,包括了4次上下文切换(4次用户态和内核态的切换),4次数据拷贝(两次CPU拷贝以及两次的DMA拷贝 ),什么是DMA拷贝呢?我们一起来回顾下,零拷贝涉及的操作系统知识点。
3.零拷贝相关知识点
1)内核空间和用户空间
操作系统为每个进程都分配了内存空间,一部分是用户空间,一部分是内核空间。内核空间是操作系统内核访问的区域,是受保护的内存空间,而用户空间是用户应用程序访问的内存区域。 以32位操作系统为例,它会为每一个进程都分配了4G (2的32次方)的内存空间。
- 内核空间:主要提供进程调度、内存分配、连接硬件资源等功能
- 用户空间:提供给各个程序进程的空间,它不具有访问内核空间资源的权限,如果应用程序需要使用到内核空间的资源,则需要通过系统调用来完成。进程从用户空间切换到内核空间,完成相关操作后,再从内核空间切换回用户空间。
2)用户态&内核态
- 如果进程运行于内核空间,被称为进程的内核态
- 如果进程运行于用户空间,被称为进程的用户态。
3)上下文切换
cpu上下文
CPU 寄存器,是CPU内置的容量小、但速度极快的内存。而程序计数器,则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。它们都是 CPU 在运行任何任务前,必须的依赖环境,因此叫做CPU上下文。
cpu上下文切换
它是指,先把前一个任务的CPU上下文(也就是CPU寄存器和程序计数器)保存起来,然后加载新任务的上下文到这些寄存器和程序计数器,最后再跳转到程序计数器所指的新位置,运行新任务。
一般我们说的上下文切换 ,就是指内核(操作系统的核心)在CPU上对进程或者线程进行切换。进程从用户态到内核态的转变,需要通过系统调用 来完成。系统调用的过程,会发生CPU上下文的切换 。
4)DMA技术
DMA,英文全称是Direct Memory Access ,即直接内存访问。DMA 本质上是一块主板上独立的芯片,允许外设设备和内存存储器之间直接进行IO数据传输,其过程不需要CPU的参与 。
我们一起来看下IO流程,DMA帮忙做了什么事情。
可以发现,DMA做的事情很清晰啦,它主要就是帮忙CPU转发一下IO请求,以及拷贝数据 。
之所以需要DMA,主要就是效率,它帮忙CPU做事情,这时候,CPU就可以闲下来去做别的事情,提高了CPU的利用效率。
4.kafka消费的zero-copy
1)实现原理
零拷贝并不是没有拷贝数据,而是减少用户态/内核态的切换次数以及CPU拷贝的次数。零拷贝实现有多种方式,分别是
- mmap+write
- sendfile
在服务端那里,我们已经知道了kafka索引文件使用的mmap来进行零拷贝优化的,现在告诉你kafka消费者在读取消息的时候使用的是sendfile来进行零拷贝优化。
linux 2.4版本之后,对sendfile做了优化升级,引入SG-DMA技术,其实就是对DMA拷贝加入了scatter/gather操作,它可以直接从内核空间缓冲区中将数据读取到网卡。使用这个特点搞零拷贝,即还可以多省去一次CPU拷贝 。
sendfile+DMA scatter/gather实现的零拷贝流程如下:
- 用户进程发起sendfile系统调用,上下文(切换1)从用户态转向内核态。
- DMA控制器,把数据从硬盘中拷贝到内核缓冲区。
- CPU把内核缓冲区中的文件描述符信息 (包括内核缓冲区的内存地址和偏移量)发送到socket缓冲区
- DMA控制器根据文件描述符信息,直接把数据从内核缓冲区拷贝到网卡
- 上下文(切换2)从内核态切换回用户态 ,sendfile调用返回。
可以发现,sendfile+DMA scatter/gather实现的零拷贝,I/O发生了2 次用户空间与内核空间的上下文切换,以及2次数据拷贝。其中2次数据拷贝都是包DMA拷贝 。这就是真正的 零拷贝(Zero-copy) 技术,全程都没有通过CPU来搬运数据,所有的数据都是通过DMA来进行传输的。
2)底层实现
Kafka数据传输通过 TransportLayer 来完成,其子类 PlaintextTransportLayer 通过Java NIO 的 FileChannel 的 transferTo 和 transferFrom 方法实现零拷贝。底层就是sendfile。消费者从broker读取数据,就是由此实现。
@Override
public long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {
return fileChannel.transferTo(position, count, socketChannel);
}
tips: transferTo 和 transferFrom 并不保证一定能使用零拷贝。实际上是否能使用零拷贝与操作系统相关,如果操作系统提供 sendfile 这样的零拷贝系统调用,则这两个方法会通过这样的系统调用充分利用零拷贝的优势,否则并不能通过这两个方法本身实现零拷贝。
4 总结
文章第一部分为大家讲解了高性能常见的优化手段,从”秘籍”和”道法”两个方面来诠释高性能设计之路该如何走,并引申出计算和IO两个优化方向。
文章第二部分是kafka内部高性能的具体设计——分别从生产者、服务端、消费者来进行全方位讲解,包括其设计、使用及相关原理。
希望通过这篇文章,能够使大家不仅学习到相关方法论,也能明白其方法论具体的落地方案,一起学习,一起成长。
作者:京东物流 李鹏
来源:京东云开发者社区
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net