图解 Kafka 超高并发网络架构演进过程

深碍√TFBOYSˉ_ 2024-04-08 10:09 83阅读 0赞

上一篇作为专题系列的第一篇，我们深度剖析了关于 Kafka 存储架构设计的实现细节，今天开启第二篇，我们来深度剖析下「**Kafka Broker 端网络架构和请求处理流程**」是如何设计的? 相信使用过 Kafka 的朋友都知道其吞吐量可以高达百万，但很少人理解其中的设计原理。

**那么 Kafka Broker 端网络架构和请求处理到底是使用了哪些高大上的技术？它到底解决了什么问题？究竟是怎么解决的？**

**只有了解了这些， 我们才能深刻掌握 Kafka 服务端设计精髓所在，更加深刻理解一个高并发、高性能服务端架构该如何设计。**

认真读完这篇文章，我相信你会对Kafka Broker请求处理流程和网络架构设计实现细节，有更加深刻的理解。

这篇文章干货很多，希望你可以耐心读完。

![b02946cf1a125355634e860016d47144.png][]

### 01 总体概述 ###

要想理解 Kafka Broker 请求处理架构设计，我们需要从简单请求处理模型来说起。

对于日常系统开发，我们都知道是基于 Request/Response 的模式来实现的， 对于 Kafka 来说， 无论是 Producer 端、Consumer 端 还是 Broker 端，他们之间的请求交互也都是基于「**Request/Response**」模式来完成的。比如，客户端会通过网络发送消息生产请求给 Broker，而 Broker 处理完成后，会发送对应的响应给到客户端。

下面，我会从自我设计角度出发，如果是我们会如何设计，带你一步步演化出来「**kafka Broker 的网络请求处理**」架构。

在这个过程中，你会看到 Kafka 在处理请求的过程中会遇到哪些高性能和高并发问题，以及架构为什么要这样演进，从而理解 Kafka 这么设计的意义和精妙之处。

### 02 顺序处理模式 ###

我们从最简单的网络编程思路处理方式讲起。

因为对于 Kafka Broker 来说就是用来接收生产者发送过来的请求，那这个时候最简单的实现大概是这样的：

![0e0b7d4b02eb249f989dd5b66095ff31.png][]

如上述代码所示：我们可以理解 Kafka 每个服务器启动起来后就是一个 while 循环， 不断的 accept 生产者提交上来的请求， 然后进行处理并存储到磁盘上，这种方式实现最简单，也非常好理解，但是这种方式存在2个致命的缺陷？

> 1.  **请求阻塞：** 只能顺序处理每个请求，即每个请求都必须等待前一个请求处理完毕才能得到处理。
> 2.  **吞吐量非常差：** 由于只能顺序处理，无法并发，效率太低，所以吞吐量非常差，只适合请求发送非常不频繁的系统。

从上面来看很明显，如果你的 Kafka 系统请求并发量很大，意味着要处理的时间就会越久。那按照前面我们提到的 Kafka「**吞吐量**」的标准，这个方案远远无法满足我们对高性能、高并发的要求。

那有什么更好的方案可以快速处理请求吗？

接下来我们可以试着采取这个方案：**独立线程异步处理模式**。

### 03 多线程异步处理模式 ###

既然同步方式会阻塞请求，吞吐量差， 我们可以尝试着使用独立线程异步方式进行处理， 即经典的 **connection per thread** 模型， 那这个时候的实现大概是这样的：

![d95af0c2af6326011dda1b6c7dfbab6c.png][]

如上述代码所示：同上还是一个 while 循环不断的 accept 生产者提交上来的请求，但是这时候 Kafka 系统会为每个请求都创建一个「**单独的线程**」来处理。

这个实现方案的好处就是：

> 1.  **吞吐量稍强：** 相对上面同步方式的方案，一定程度上极大地提高了服务器的吞吐量。
> 2.  **非阻塞：** 它是完全异步的，每个请求的处理都不会阻塞下一个请求。

但同样缺陷也同样很明显：**即为每个请求都创建线程的做法开销很大**，在某些高并发场景下会压垮整个服务。可见，这个方案也只适用于请求发送频率很低的业务场景。还是无法满足我们对高性能、高并发的要求。

既然这种方案还是不能满足， 那么我们究竟该使用什么方案来支撑高并发呢？

这个时候我们可以想想我们日常开发用到的7层负载Nginx或者Redis在处理高并发请求的时候是使用什么方案呢？

从上面启发你可以看出，提升系统 I/O 并发性能的关键思路就是：「**事件驱动**」。

想必大家已经猜到了，没错，就是「**多路复用**」。那么Kafka 是不是也是采用这种方案来实现呢？

这里我们先考虑采用基于「**事件驱动**」的设计方案，当有事件触发时，才会调用处理器进行数据处理。

### 04 Reactor 模式 ###

在高性能网络编程领域，有一个非常著名的模式——Reactor模式。那么何为「**Reactor模式**」，首先它是基于事件驱动的，有一个或多个并发输入源，有一个Service Handler，有多个Request Handler；这个Service Handler会同步的将输入的请求轮询地分发给相应的Request Handler进行处理。

借助于 Doug Lea（就是那位让人无限景仰的大爷）的 "Scalable IO in Java" 中讲述的Reactor模式。

"Scalable IO in Java" 的地址是：

http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf

简单来说，**Reactor 模式特别适合应用于处理多个客户端并发向服务器端发送请求的场景**。这里借用大神 PDF 中的一幅图来说明 Reactor 架构：

![c2e94e69ac6486b37746e9a78c54ba77.png][]

从上面这张图中，我们可以看出多个客户端会发送请求给到 Reactor。Reactor 有个请求分发

[b02946cf1a125355634e860016d47144.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/75024bcdf12045fe9614daad3ca27195.png
[0e0b7d4b02eb249f989dd5b66095ff31.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/27550c51149649799301daa90b5fb73c.png
[d95af0c2af6326011dda1b6c7dfbab6c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/e132255400954e59a031968e3fd7e4c3.png
[c2e94e69ac6486b37746e9a78c54ba77.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/c3d90ce2c2e74feab2db5e7b68adb2e5.png