1 前言

信任各位小伙伴之前或多或少接触过音讯行列，比较知名的包含Rocket MQ和Kafka，在京东内部运用的是自研的音讯中间件JMQ，从JMQ2晋级到JMQ4的也是带来了功用上的明显进步，而且JMQ4的底层也是参阅Kafka去做的规划。在这儿我会给咱们展示Kafka它的高功用是怎么规划的，咱们也能够学习相关办法论将其运用在实践项目中，也许下一个尖端项目就在各位的代码中产生了。

2 怎么了解高功用规划

2.1 高功用规划的”秘籍”

先抛开kafka，咱们先来议论一下高功用规划的实质，在这儿借用一下网上的一张总结高功用的思维导图：

从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中学习高性能系统如何设计 | 京东云技术团队

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中学习高性能系统如何设计 | 京东云技术团队

之前现已说了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，详细功率比照方下：

从Kafka中学习高性能系统如何设计 | 京东云技术团队

3.2 服务端的高功用规划

3.2.1 Reactor网络通信模型

kafka比较其他音讯中间件最出彩的当地在于他的高吞吐量，那么关于服务端来说每秒的恳求压力将会巨大，需求有一个优异的网络通信机制来处理海量的恳求。假如 IO 有所研讨的同学，应该清楚：Reactor 形式正是采用了很经典的 IO 多路复用技能，它能够复用一个线程去处理很多的 Socket 衔接，然后确保高功用。Netty 和 Redis 为什么能做到十万乃至百万并发？它们其实都采用了 Reactor 网络通信模型。

1.kafka网络通信层架构

从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中学习高性能系统如何设计 | 京东云技术团队

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.稀少索引

从Kafka中学习高性能系统如何设计 | 京东云技术团队

能够从上面看到，一个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。

从Kafka中学习高性能系统如何设计 | 京东云技术团队

这儿以offsetIndex为例子来胪陈kafka的二分查找算法：
1）一般二分查找
offsetIndex每个索引项巨细是8B，但操作体系拜访内存时的最小单元是页，一般是4KB，即4096B，会包含了512个索引项。而找出在索引中的指定偏移量，关于操作体系拜访内存时则变成了找出指定偏移量所在的页。假定索引的巨细有13个页，如下图所示：

从Kafka中学习高性能系统如何设计 | 京东云技术团队

因为Kafka读取音讯，一般都是读取最新的偏移量，所以要查询的页就集中在尾部​，即第12号页上。依据二分查找，将顺次拜访6、9、11、12号页。

从Kafka中学习高性能系统如何设计 | 京东云技术团队

当跟着Kafka接纳音讯的添加，索引文件也会添加至第13号页，这时依据二分查找，将顺次拜访7、10、12、13号页。

从Kafka中学习高性能系统如何设计 | 京东云技术团队

能够看出拜访的页和上一次的页完全不同。之前在只要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被判定为热区。假定咱们读取的是最新的音讯，则在热区中进行二分查找的状况如下：

从Kafka中学习高性能系统如何设计 | 京东云技术团队

当12号页未满时，顺次拜访11、12号页，当12号页满时，拜访页的状况相同。当13号页出现的时分，顺次拜访12、13号页，不会出现拜访长时刻未拜访的页，则能有用防止缺页中断。

3.mmap的运用

运用稀少索引，现已根本解决了高效查询的问题，可是这个进程中依然有进一步的优化空间，那便是经过 mmap（memory mapped files） 读写上面说到的稀少索引文件，进一步进步查询音讯的速度。

究竟怎么了解 mmap？前面说到，惯例的文件操作为了进步读写功用，运用了 Page Cache 机制，可是因为页缓存处在内核空间中，不能被用户进程直接寻址，所以读文件时还需求经过体系调用，将页缓存中的数据再次仿制到用户空间中。

1）惯例文件读写

从Kafka中学习高性能系统如何设计 | 京东云技术团队

  • app拿着inode查找读取文件
  • address_space中存储了inode和该文件对应页面缓存的映射联系
  • 页面缓存缺失，引发缺页反常
  • 经过inode找到磁盘地址，将文件信息读取并填充到页面缓存
  • 页面缓存处于内核态，无法直接被app读取到，因而要先仿制到用户空间缓冲区，此处发生内核态和用户态的切换

tips：这一进程实践上发生了四次数据仿制。首要经过体系调用将文件数据读入到内核态Buffer（DMA仿制），然后运用程序将内存态Buffer数据读入到用户态Buffer（CPU仿制），接着用户程序经过Socket发送数据时将用户态Buffer数据仿制到内核态Buffer（CPU仿制），最后经过DMA仿制将数据仿制到NIC Buffer。一同，还伴跟着四次上下文切换。

2）mmap读写形式

从Kafka中学习高性能系统如何设计 | 京东云技术团队

  • 调用内核函数mmap()，在页表(类比虚拟内存PTE)中树立了文件地址和虚拟地址空间中用户空间的映射联系
  • 读操作引发缺页反常，经过inode找到磁盘地址，将文件内容仿制到用户空间，此处不触及内核态和用户态的切换

tips：采用 mmap 后，它将磁盘文件与进程虚拟地址做了映射，并不会招致体系调用，以及额定的内存 copy 开支，然后进步了文件读取功率。详细到 Kafka 的源码层面，便是依据 JDK nio 包下的 MappedByteBuffer 的 map 函数，将磁盘文件映射到内存中。只要索引文件的读写才用到了 mmap。

3.2.4 音讯存储-磁盘次序写

关于咱们常用的机械硬盘，其读取数据分3步：

  1. 寻道；
  2. 寻觅扇区；
  3. 读取数据；

前两个，即寻觅数据方位的进程为机械运动。咱们常说硬盘比内存慢，首要原因是这两个进程在拖后腿。不过，硬盘比内存慢是绝对的吗？其实不然，假如咱们能经过次序读写削减寻觅数据方位时读写磁头的移动间隔，硬盘的速度仍是相当可观的。一般来讲，IO速度层面，内存次序IO > 磁盘次序IO > 内存随机IO > 磁盘随机IO。这儿用一张网上的图来比照一下相关IO功用：

从Kafka中学习高性能系统如何设计 | 京东云技术团队

Kafka在次序IO上的规划分两方面看：

  1. LogSegment创建时，一口气恳求LogSegment最大size的磁盘空间，这样一个文件内部尽或许分布在一个连续的磁盘空间内；
  2. .log文件也好，.index和.timeindex也罢，在规划上都是只追加写入，不做更新操作，这样防止了随机IO的场景；

3.2.5 Page Cache的运用

从Kafka中学习高性能系统如何设计 | 京东云技术团队

为了优化读写功用，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缓冲区，最后写入网卡设备
    流程图如下：

从Kafka中学习高性能系统如何设计 | 京东云技术团队

  • 用户运用进程调用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帮助做了什么工作。

从Kafka中学习高性能系统如何设计 | 京东云技术团队

能够发现，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完结的零仿制流程如下：

从Kafka中学习高性能系统如何设计 | 京东云技术团队

  • 用户进程建议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内部高功用的详细规划——别离从生产者、服务端、顾客来进行全方位解说，包含其规划、运用及相关原理。

期望经过这篇文章，能够使咱们不仅学习到相关办法论，也能明白其办法论详细的落当地案，一同学习，一同成长。

作者：京东物流 李鹏

来历：京东云开发者社区