kafka是如何做到高效的

痛定思痛。 2023-05-31 07:25 12阅读 0赞

上篇文章是我们在设计系统的如何让它做到高可用，这篇文章学习一下在设计时候如何把消息队列设计的高效，当然这个还是以kafka为原型去学习，首先从整体上看，有哪些措施导致了kafka的快呢？

总体架构：

*  利用Partition实现并行处理
 *  ISR实现可用性与数据一致性的动态平衡

具体设计：

*  顺序写磁盘
 *  充分利用Page Cache
 *  零拷贝
 *  批处理
 *  高效的序列化方式
 *  数据压缩降低网络负载
 *  Kafka客户端和服务端通信采取的是NIO的reactor模式，它是一种事件驱动模式

### 总体架构 ###

#### 1. 利用Partition实现并行处理： ####

*  由于不同Partition可位于不同机器，因此可以充分利用集群优势，实现机器间的并行处理。
 *  由于Partition在物理上对应一个文件夹，即使多个Partition位于同一个节点，也可通过配置让同一节点上的不同Partition置于不同的disk drive上，从而实现磁盘间的并行处理，充分发挥多磁盘的优势。虽然物理上最小单位是Segment，但Kafka并不提供同一Partition内不同Segment间的并行处理。因为对于写而言，每次只会写Partition内的一个Segment，而对于读而言，也只会顺序读取同一Partition内的不同Segment。Partition个数决定了可能的最大并行度。

#### 2. ISR实现可用性与数据一致性的动态平衡： ####

*  由于Leader可移除不能及时与之同步的Follower，故与同步复制相比可避免最慢的Follower拖慢整体速度，也即ISR提高了系统可用性。
 *  ISR中的所有Follower都包含了所有Commit过的消息，而只有Commit过的消息才会被Consumer消费，故从Consumer的角度而言，ISR中的所有Replica都始终处于同步状态，从而与异步复制方案相比提高了数据一致性。
 *  ISR可动态调整，极限情况下，可以只包含Leader，极大提高了可容忍的宕机的Follower的数量。与MajorityQuorum方案相比，容忍相同个数的节点失败，所要求的总节点数少了近一半。

### 具体设计 ###

#### 1. 顺序写磁盘： ####

*  Kafka的整个设计中，Partition相当于一个非常长的数组，而Broker接收到的所有消息顺序写入这个大数组中。同时Consumer通过Offset顺序消费这些数据，并且不删除已经消费的数据，从而避免了随机写磁盘的过程。
 *  由于磁盘有限，不可能保存所有数据，实际上作为消息系统Kafka也没必要保存所有数据，需要删除旧的数据。而这个删除过程，并非通过使用“读-写”模式去修改文件，而是将Partition分为多个Segment，每个Segment对应一个物理文件，通过删除整个文件的方式去删除Partition内的数据。这种方式清除旧数据的方式，也避免了对文件的随机写操作。

#### 2. 充分利用Page Cache ####

*  I/O Scheduler会将连续的小块写组装成大块的物理写从而提高性能
 *  I/O Scheduler会尝试将一些写操作重新按顺序排好，从而减少磁盘头的移动时间
 *  充分利用所有空闲内存（非JVM内存）。如果使用应用层Cache（即JVM堆内存），会增加GC负担
 *  读操作可直接在Page Cache内进行。如果消费和生产速度相当，甚至不需要通过物理磁盘（直接通过Page Cache）交换数据
 *  如果进程重启，JVM内的Cache会失效，但Page Cache仍然可用

#### 3. 零拷贝 ####

Kafka中存在大量的网络数据持久化到磁盘（Producer到Broker）和磁盘文件通过网络发送（Broker到Consumer）的过程。这一过程的性能直接影响Kafka的整体吞吐量。

buffer = File.read
    Socket.send(buffer)

这一过程实际上发生了四次数据拷贝。首先通过系统调用将文件数据读入到内核态Buffer（DMA拷贝），然后应用程序将内存态Buffer数据读入到用户态Buffer（CPU拷贝），接着用户程序通过Socket发送数据时将用户态Buffer数据拷贝到内核态Buffer（CPU拷贝），最后通过DMA拷贝将数据拷贝到NIC Buffer。

Linux 2.4+内核通过sendfile系统调用，提供了零拷贝。数据通过DMA拷贝到内核态Buffer后，直接通过DMA拷贝到NIC Buffer，无需CPU拷贝。这也是零拷贝这一说法的来源。除了减少数据拷贝外，因为整个读文件-网络发送由一个sendfile调用完成，整个过程只有两次上下文切换，因此大大提高了性能。

#### 4. 批处理 ####

Kafka 0.8.2开始支持新的Producer API，将同步Producer和异步Producer结合。虽然从send接口来看，一次只能发送一个ProducerRecord，而不能像之前版本的send方法一样接受消息列表，但是send方法并非立即将消息发送出去，而是通过batch.size和linger.ms控制实际发送频率，从而实现批量发送。

由于每次网络传输，除了传输消息本身以外，还要传输非常多的网络协议本身的一些内容（称为Overhead），所以将多条消息合并到一起传输，可有效减少网络传输的Overhead，进而提高了传输效率。

#### 5. 高效的序列化方式 ####

Kafka消息的Key和Payload（或者说Value）的类型可自定义，只需同时提供相应的序列化器和反序列化器即可。因此用户可以通过使用快速且紧凑的序列化-反序列化方式（如Avro，Protocal Buffer）来减少实际网络传输和磁盘存储的数据规模，从而提高吞吐率。这里要注意，如果使用的序列化方法太慢，即使压缩比非常高，最终的效率也不一定高。

#### 6. 数据压缩降低网络负载 ####

Kafka从0.7开始，即支持将数据压缩后再传输给Broker。除了可以将每条消息单独压缩然后传输外，Kafka还支持在批量发送时，将整个Batch的消息一起压缩后传输。数据压缩的一个基本原理是，重复数据越多压缩效果越好。因此将整个Batch的数据一起压缩能更大幅度减小数据量，从而更大程度提高网络传输效率。

Broker接收消息后，并不直接解压缩，而是直接将消息以压缩后的形式持久化到磁盘。Consumer Fetch到数据后再解压缩。因此Kafka的压缩不仅减少了Producer到Broker的网络传输负载，同时也降低了Broker磁盘操作的负载，也降低了Consumer与Broker间的网络传输量，从而极大得提高了传输效率，提高了吞吐量。

#### 7. NIO的reactor模式 ####

Kafka客户端和服务端通信采取的是NIO的reactor模式，它是一种事件驱动模式。那么一个常见的单线程Reactor模式下，NIO线程的职责都有哪些呢？我们整理了如下几点：

1.  作为NIO服务端，接收客户端的TCP连接
2.  作为NIO客户端，向服务端发起TCP连接
3.  读取通信对端的请求或者应答消息
4.  向通信对端发送消息请求或者应答消息

参考地址：

http://www.jasongj.com/kafka/high\_throughput/

https://www.okcode.net/article/38883

https://cloud.tencent.com/developer/article/1114834

https://www.cnblogs.com/swordfall/p/10193336.html

https://xenojoshua.com/2019/04/kafka-note/

http://www.360linker.com/wfw/577.jhtml

https://www.jianshu.com/p/7c7218885d26