我们知道kafka是一款高吞吐量的，性能极高的消息处理引擎系统，常用于日志收集、数据缓冲、异步通信解耦等。那么它是如何做到高性能的呢？
本章要点
- 架构层次
- 实现层次
1. 架构层次
1.1 分区
我们知道kafka是个分布式集群的系统，整个系统可以包含多个broker。每个topic会有多个分区，kafka将分区均匀地分配到整个集群中，当生产者向对应主题传递消息时，消息通过负载均衡机制传递到不同的分区以减轻单个服务器实例的压力。
2.实现层次
- 2.1 异步化的线程模型
- 2.2 高性能的异步网络传输
- 2.3 自定义的私有传输协议
- 2.4 自定义的序列化、反序列化
2.5 批量处理：
批量处理绝对是一种非常有效的提升系统吞吐量的方法。
虽然kafka只提供单条发送的API，send方法，当我们调用kafka的API，Producer的send方法的时，它不会立即发送出这个消息，而是会把消息暂时在内存中缓存起来，然后会在何时的时候把混存中的所有消息组成一批，一次性发到Broker。
而，Broker在处理消息时，是把批量发送的消息，当作一个“批消息”来处理，Broker在整个处理流程中，无论是读写磁盘，还是复制副本，都不会将批消息进行一一拆开，一直视为一条“批消息”进行处理。
拆分的工作是在消费端进行处理的
2.6 顺序读写磁盘
磁盘IO的速度是比较慢的，所以对于Broker来说，磁盘IO是性能的瓶颈。
对于磁盘来说顺序读写的性能要远远好于随机读写。这是因为操作系统每次从磁盘读写数据的时候，需要先寻址，也就是要先找到数据在磁盘的物理位置，然后在进行数据读写。
顺序读写比随机读写省去了大部分的寻址的时间，他只要寻址一次，就可以连续读写下去。所以性能要好多很。
Kafka充分利用的磁盘的顺序读写的特性，它的存储，对于每个分区来说，它把从Producer收到的消息，顺序的写入对应的log文件中，一个文件写满之后，就开启一个新的文件，继续顺序的写下去。消费的时候也是从某个全局的位置开始，顺序的把消息读出来。
2.7 充分利用 PageCache 加速消息读写
Kafka中，充分利用了PageCache加速消息读写。
PageCache是现代操作系统都具有的一项基本特性。它是操作系统在内存中给磁盘上的文件建立的缓存。
当我们在调用系统的API进行文件读写的时候，并不会直接去读写磁盘上的文件，应用程序实际操作的都是PageCache，即文件在内存中缓存的副本。
文件写：应用程序在写入文件的时候，操作系统会先把数据写入到内存中的PageCache，然后再一批批的写到磁盘上。
文件读：读文件的时候，会PageCache中读取数据；如果有数据，则直接读取，省去了读取磁盘的时间；如果没有则，操作系统首先会阻塞应用程序读取操作的线程（缺页中断），紧接着操作系统把数据从磁盘中复制到PageCache中，最后应用程序再从PageCache中读取数据。
这样就加速了文件消息读读写操作。
用户的应用程序在使用完某块PageCache后，操作系统并不会立刻就清除这个PageCache，而是尽可能地利用空闲的物理内存保存这些 PageCache,除非系统内存不够用,操作系统才会清理一部分PageCache。清理策略一般是LRU，即有限保留最近一段时间常用的那些PageCache。
2.8 ZeroCopy：零拷贝技术
Kafka 的服务端在消费过程中,还使用了一种“零拷贝”的操作系统特性来进一步提升消费的性能。
Broker处理消息大致过程：1.从文件中找到消息，读取到内存中 2.把消息通过网络发给客户端
这个过程需要经过消息复制如下：
- 1.从文件中复制数据到PageCache中，如果命中PageCache，则这步省略
- 2.从PageCache复制到应用程序的内存空间中，即我们可以操作的对象所在的内存
- 3.从应用程序的内存空间复制到Socket的缓存区
- 4.操作系统将Socket缓存区的数据，复制到网卡缓存区
使用零拷贝技术可以把这个复制次数减少一次，上面的2、3步骤两次复制合并成一次复制。
直接从 PageCache 中把数据复制到 Socket 缓冲区中,这样不仅减少一次数据复制,更重要的是，由于不用把数据复制到用户内存中，DMA(Direct Memory Access，直接内存存取)控制器可以完成数据复制，不需要CPU参与，速度更快。
网友评论