大数据中台之Kafka到底好在哪里

-8-大数据中台之Kafka，到底好在哪里？在kafka-0.8版本的设计中，生产者往服务端发送数据，是一条发送一次，这样吞吐量低，后来的版本里面加了缓冲区和批量提交的概念，一下子吞吐量提高了许多。

优秀设计之基于NIO编程

Kafka底层的IO用的是NIO，这个事虽然简洁，但是也需要提一提。我们开发一个分布式文件系统的时候避开不了需要思索需要什么样的IO？BIO性能较差，NIO性能要比BIO要好许多，而且编程难度也不算大，当然性能最好的那就是AIO了，但是AIO编程难度较大，代码设计起来较为简单，所以Kafka选择的是NIO，也是由于这些缘由，目前我们看到许多开源的技术也都是用的NIO。

优秀设计之高性能网络设计

个人认为Kafka的网络部分的代码设计是整个Kafka比较精华的部分。我们接下来一步一步分析一下KafkaServer端为了支持超高并发是如何设计其网络架构的？

我们先不看kafka本身的网络架构，我们先简洁了解一下Reactor模式：

图1Reactor模型

(1)首先服务端创建了ServerSocketChannel对象并在Selector上注册了OP_ACCEPT大事，ServerSocketChannel负责监听指定端口上的连接。

（2）当客户端发起到服务端的网络连接恳求时，服务端的Selector监听到OP_ACCEPT大事，会触发Acceptor来处理OP_ACCEPT大事.

（3）当Acceptor接收到来自客户端的socket恳求时会为这个连接创建对应的SocketChannel，将这个SocketChannel设置为非堵塞模式，并在Selector上注册它关注的I/O大事。如：OP_WRITER,OP_READ大事。此时客户端与服务端的socket连接正式建立完成。

（4）当客户端通过上面建立好的socket连接向服务端发送恳求时，服务端的Selector会监听到OP_READ大事，并触发对应的处理规律（readhandler）。服务端像客户端发送响应时，服务端的Selector可以监听到OP_WRITER大事，并触发对应的处理规律（writerhandler）。

我们看到这种设计就是将全部的大事处理都在同一个线程中完成。这样的设计适合用在客户端这种并发比较小的场景。假如并发量比较大，或者有个恳求处理规律要较为简单，耗时较长，那么就会影响到后续全部的恳求，接着就会导致大量的任务超时。要解决这个问题，我们对上述的架构稍作调整，如下图所示：

图2Reactor改进模型

Accept单独运行在一个线程中，这个线程使用ExecutorService实现，由于这样的话，当Accept线程特别退出的时候，ExecutorService也会创建新的线程进行补偿。Readhandler里面也是一个线程池，这个里面全部的线程都注册了OP_READ大事，负责接收客户端传过来的恳求，当然也是一个线程对应了多个socket连接。Readhandler里的线程接收到恳求以后把恳求都存入到MessageQueue里面。HandlerPoll线程池中的线程就会从MessageQueue队列里面猎取恳求，然后对恳求进行处理。这样设计的话，即使某个恳求需要大量耗时，HandlerPoll线程池里的其它线程也会去处理后面的恳求，避开了整个服务端的堵塞。当恳求处理完了以后handlerPool中的线程注册OP_WRITER大事，实现往客户端发送响应的功能。

通过这种设计就解决了性能瓶颈的问题，但是假如突然发生了大量的网络I/O。单个Selector可能会在分发大事的时候成为性能瓶颈。所以我们很简单想的到应当将上面的单独的Selector扩展为多个，所以架构图就变成了如下的这幅图：

图3Reactor改进模型

假如我们理解了上面的设计以后，再去理解Kafka的网络架构就简洁多了，如下图所示：

图4Kafka网络模型

这个就是Kafka的Server端的网络架构设计，就是根据前面的网路架构演化出来的。Accepetor启动了以后接收连接恳求，接收到了恳求以后把恳求发送给一个线程池（Processor）线程池里的每个线程猎取到恳求以后，把恳求封装为一个个SocketChannel缓存在自己的队列里面。接下来给这些SocketChannel注册上OP_READ大事，这样就可以接收客户端发送过来的恳求了，Processor线程就把接收到的恳求封装成Request对象存入到RequestChannel的RequestQueue队列。接下来启动了一个线程池，默认是8个线程来对队列里面的恳求进行处理。处理完了以后把对应的响应放入到对应ReponseQueue里面。每个Processor线程从其对应的ReponseQueue里面猎取响应，注册OP_WRITER大事，最终把响应发送给客户端。

个人觉得Kafka的网络设计部分代码设计得很美丽，就是由于这个网络架构，保证了kafka的高性能。

优秀设计之挨次写

一开头许多人质疑kafka，大家认为一个架构在磁盘之上的系统，性能是如何保证的。这点需要跟大家解释一下，客户端写入到Kafka的数据首先是写入到操作系统缓存的（所以很快），然后缓存里的数据依据肯定的策略再写入到磁盘，并且写入到磁盘的时候是挨次写，挨次写假如磁盘的个数和转数跟得上的话，都快赶上写内存的速度了！

优秀设计之跳表、稀松索引、零拷贝

上面我们看到kafka通过挨次写的设计保证了高效的写性能，那读数据的高性能又是如何设计的呢？kafka是一个消息系统，里面的每个消息都会有offset，假如消费者消费某个offset的消息的时候是如何快速定位呢？

01/跳表

如下截图是我们线上的kafka的存储文件，里面有两个重要的文件，一个是index文件，一个是log文件。

图5Kafka存储文件

log文件里面存储的是消息，index存储的是索引信息，这两个文件的文件名都是一样的，成对消失的，这个文件名是以log文件里的第一条消息的offset命名的，如下第一个文件的文件名叫00000000000012768089，代表着这个文件里的第一个消息的offset是12768089，也就是说其次条消息就是12768090了。

在kafka的代码里，我们一个的log文件是存储是ConcurrentSkipListMap里的，是一个map结构，key用的是文件名（也就是offset），value就是log文件内容。而ConcurrentSkipListMap是基于跳表的数据结构设计的。

图6concurrentSkipListMap设计

这样子，我们想要消费某个大小的offset，可以依据跳表快速的定位到这个log文件了。

02/稀松索引

经过上面的步骤，我们仅仅也就是定位了log文件而已，但是要消费的数据详细的物理位置在哪儿？，我们就得靠kafka的稀松索引了。假设刚刚我们定位要消费的偏移量是在00000000000000368769.log文件里，假如说要整个文件遍历，然后一个offset一个offset比对，性能确定很差。这个时候就需要借助刚刚我们看到的index文件了，这个文件里面存的就是消息的offset和其对应的物理位置，但index不是为每条消息都存一条索引信息，而是每隔几条数据才存一条index信息，这样index文件其实很小，也就是这个缘由我们就管这种方式叫稀松索引。

图7稀松索引

比如现在我们要消费offset等于368776的消息，如何依据index文件定位呢？（1）首先在index文件里找，index文件存储的数据都是成对消失的，比如我们到的1，0代表的意思是，offset=368769+1=368770这条信息存储的物理位置是0这个位置。那现在我们现在想要定位的消息是368776这条消息，368776减去368769等于7，我们就在index文件里找offset等于7对应的物理位置，但是由于是稀松索引，我们没找到，不过我们找到了offset等于6的物理值1407。

（2）接下来就到log文件里读取文件的1407的位置，然后遍历后面的offset，很快就可以遍历到offset等于7(368776)的数据了，然后从这儿开头消费即可。

03/零拷贝

接下来消费者读取数据的流程用的是零拷贝技术，我们先看一下如下是非零拷贝的流程：

（1）操作系统将数据从磁盘文件中读取到内核空间的页面缓存；

（2）应用程序将数据从内核空间读入用户空间缓冲区；

（3）应用程序将读到数据写回内核空间并放入socket缓冲区；

（4）操作系统将数据从socket缓冲区复制到网卡接口，此时数据才能通过网络发送。

图8非零拷贝流程

上图我们发觉里面会涉及到两次数据拷贝，Kafka这儿为了提升性能，所以就采纳了零拷贝，零拷贝'只用将磁盘文件的数据复制到页面缓存中一次，然后将数据从页面缓存直接发送到网络中（发送给不同的订阅者时，都可以使用同一个页面缓存），避开了重复复制操作，提升了整个读数据的性能。

图9零拷贝流程

优秀设计之批处理

在kafka-0.8版本的设计中，生产者往服务端发送数据，是一条发送一次，这样吞吐量低，后来的版本里面加了缓冲区和批量提交的概念，一下子吞吐量提高了许多。下图就是修改过后的生产者发送消息的原理图：（