Kafka 系列第 4 篇:消息发送时,网络“偷偷”帮忙做的那点事儿


前言
上篇文章讲述了消息从生产到写入到 Broker 的 partition 上背后发生的故事,并提出了消息发送的网络模型的问题。本篇文章我们来尝试揭开其背后的神秘面纱,耐心看完你一定会有所收获。
文章概览
Sender 线程的建连准备阶段和发送网络请求两阶段。
Selector 选择器处理网络请求过程。
Sender 线程的两阶段
上篇文章结尾提到了三个重要的方法,分别是 ready()、send()、poll()。其中 ready()和 send()可以理解为第一阶段,即建连准备阶段;poll()可以理解为第二阶段,即发送网络请求阶段。接下来对这两阶段做深入研究。

阶段流程说明
ready()阶段: 遍历节点列表,查询当前是否已建立连接,若已完成建连,则认为该节点可用;若还未建连,则判断该节点是否可以被连接,若是则建连。对于不可建连和正在建连的节点暂时还不能参与网络数据传输请求。
send()阶段: 通过 ready()阶段拿到了已经完成建连的节点,然后遍历节点,判断当前节点是否可以被发送数据,若可以则将当前节点对应的 RequestChannel 加入到 InFlightRequest 双端队列中去。为什么要将 RequestChannel 加入到一个双端队列中去呢?因为服务端为了保证服务端性能,一个服务端在同一时刻只能被一个客户端请求连接,如果上一个客户端请求还未完成,则不允许新的客户端请求连接。当客户端请求接收到服务端响应后,将对应的客户端请求从 InFlightRequest 队列中移除。
poll()阶段: 通过 ready()和 send()两阶段,完成了数据准备和可用节点检查。在上一篇中我们介绍到客户端是按照 Broker 分组,每组建立一个网络连接请求,每个网络连接请求管理多个网络连接通道,从而形成了一个连接同时与多个 Broker 进行网络数据传输。poll()方法采用了选择器(Selector)模式来处理这种网络模型,其底层是使用 Java 的 NIO 来实现的。
简单介绍下 Java NIO 的几个组件,想要深入了解的同学通过 Google 去了解。
SocketChannel: 客户端网络连接通道,在此通道上可进行数据的读写操作,比如将数据写入到通道中和将数据从通道中读取出来操作。
Selector: 选择器,通道是需要注册到 Selector 选择器上的,同时在注册后会返回一个选择器建,Selector 会通过选择器键来监听读写事件。
SelectorKey: 选择器键,通道注册到选择器上,同时返回了选择器键,从而使得选择器键和通道建立了关系。
以上三者之间的关系如下:
当有读写请求发生时,Selector 可以通过 SelectorKey 拿到对应的 SocketChannel,从而在 SocketChannel 上进行数据的读写请求。
Selector 选择器的实现原理
关于 Selector 选择器,我们从两个方面来介绍其背后发生了那些故事,分别是 建连过程和读写操作流程。
Selector 建连过程分析

Kafka建连过程
从上图可以看出,首先打开一个客户端连接 SocketChannel,然后对 Socket 设置一些参数,比如写入数据大小、接受数据大小、TCP 延迟等等参数。然后使用 SocketChannel 尝试建立连接。建连完成后将 SocketChannel 注册到 Selector 选择器上,并返回 SelectorKey。最后将 SocketChannel 包装成 KafkaChannel,并使用 SelectorKey 与 KafkaChannel 进行关联;为啥会出现 KafkaChannel 了呢?因为 Kafka 框架为了屏蔽 SocketChannel 内部的细节操作,所有就对 SocketChannel 进行了一层包装方便 Kafka 客户端操作。
附上源码供大家参考研究
Selector 选择器读写操作流程

读写流程图
从上图可以看出,以写操作为例,客户端轮询到写请求时,首先获取写请求对应的 SelectorKey,从而拿到对应的 KafkaChannel;然后将要发送的数据写入到 KafkaChannel 中;然后通过传输协议将数据交由底层的 SocketChannel;最后由 SocketChannel 将数据发送给 Broker,完成数据的发送请求。该过程中需要注意一个问题,Broker 在同一时间只能处理一个客户端请求,如果当前客户端请求还没被被处理完,下一个请求是不能被发送给服务端的。
总结
以上即为数据从客户端发送到服务端背后相关的网络操作故事;到此,关于生产者客户端的相关操作暂且分析到这里,关于客户端幂等性、消息重发等问题我们在后面专门用篇幅来讲解。下篇文章我们来分析一下消费者端消费消息背后的一些故事,敬请期待。
系列文章尽在微信公众号【z小赵】,关注作者,系列文章不迷路。

版权声明: 本文为 InfoQ 作者【z小赵】的原创文章。
原文链接:【http://xie.infoq.cn/article/85ea30a57605e6e9945bbfd0e】。文章转载请联系作者。
评论