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

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

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

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

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

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

01 总体概述

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

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

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

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

02 顺序处理模式

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

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

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

  1. 请求阻塞: 只能顺序处理每个请求,即每个请求都必须等待前一个请求处理完毕才能得到处理。

  2. 吞吐量非常差: 由于只能顺序处理,无法并发,效率太低,所以吞吐量非常差,只适合请求发送非常不频繁的系统。

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

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

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

03 多线程异步处理模式

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

如上述代码所示:同上还是一个 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 架构:

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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
图解kafka之实战指南.pdf》是一本关于Kafka实践的指南书籍。Kafka是一种高吞吐量、低延迟的分布式消息系统,被广泛应用于大数据和实时流处理领域。 本书逐步介绍了Kafka的基本概念和架构,并提供了详细的实践指南。首先,书中介绍了Kafka的基本原理和术语,包括生产者、消费者、代理、分区和副本等,并通过图解的方式使读者更加直观地理解这些概念。 接着,书中详细介绍了Kafka的部署和配置。读者可以了解到如何搭建Kafka集群、如何配置生产者和消费者,并且介绍了一些常见的配置参数和调优技巧。这些内容将帮助读者实现高性能和高可用的Kafka集群。 然后,书中重点介绍了如何使用Kafka进行实时数据处理和流式计算。作者通过实际案例和代码示例,演示了如何将Kafka与其他工具(如Spark、Flink和Storm)结合使用,以实现数据的实时分析和处理。这对于需要处理大规模实时数据的企业和项目非常有实际意义。 最后,书中还介绍了一些Kafka的最佳实践和应用实例。作者结合自己的经验,提供了一些关于Kafka的使用场景、容错和监控的建议。这些实践指南将帮助读者更好地理解和使用Kafka,提高系统的可靠性和性能。 总之,《图解Kafka之实战指南.pdf》是一本系统而实用的Kafka实践指南,对于想要学习和应用Kafka的开发人员和系统架构师来说,是一本不可多得的参考书籍。通过阅读本书,读者将更加深入地理解Kafka的原理和架构,并掌握如何正确配置和使用Kafka进行实时数据处理。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值