高性能设计的” 秘籍”
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 网络通信模型
用户线程 IO 模型
这里就不赘述
3.2.2 Kafka 的底层日志结构
暂时不需要设计底层结构，所以不进行深入了解
具体看 从 Kafka 中学习高性能系统如何设计 | 京东云技术团队 - 知乎
3.2.3 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.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 这样的零拷贝系统调用，则这两个方法会通过这样的系统调用充分利用零拷贝的优势，否则并不能通过这两个方法本身实现零拷贝。