Kafka从成神到升仙系列 五面试官问我 Kafka 生产者的网络架构，我直接开始从源码背起.......
Posted 爱敲代码的小黄
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Kafka从成神到升仙系列 五面试官问我 Kafka 生产者的网络架构，我直接开始从源码背起.......相关的知识，希望对你有一定的参考价值。
- 👏作者简介：大家好，我是爱敲代码的小黄，独角兽企业的Java开发工程师，CSDN博客专家，Java领域新星创作者
- 📕系列专栏：Java设计模式、数据结构和算法、Kafka从入门到成神、Kafka从成神到升仙
- 📧如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步👀
- 🔥如果感觉博主的文章还不错的话，请👍三连支持👍一下博主哦
- 🍂博主正在努力完成2022计划中：以梦为马，扬帆起航，2022追梦人
文章目录
- Kafka 生产者的网络架构
Kafka从成神到成仙系列
Kafka 生产者的网络架构
初学一个技术，怎么了解该技术的源码至关重要。
对我而言，最佳的阅读源码的方式，那就是：不求甚解，观其大略
你如果进到庐山里头，二话不说，蹲下头来，弯下腰，就对着某棵树某棵小草猛研究而不是说先把庐山的整体脉络研究清楚了，那么你的学习方法肯定效率巨低而且特别痛苦。
最重要的还是慢慢地打击你的积极性，说我的学习怎么那么不 happy 啊，怎么那么没劲那，因为你的学习方法错了，大体读明白，先拿来用，用着用着，很多道理你就明白了。
先从整体上把关源码，再去扣一些细节问题。
举个简单的例子：
如果你刚接触 HashMap，你刚有兴趣去看其源码，在看 HashMap 的时候，有一个知识：当链表长度达到 8 之后，就变为了红黑树，小于 6 就变成了链表，当然，还和当前的长度有关。
这个时候，如果你去深究红黑树、为什么是 8 不是别的，又去查 泊松分布，最终会慢慢的搞死自己。
所以，正确的做法，我们先把这一部分给略过去，知道这个概念即可，等后面我们把整个庐山看完之后，再回过头抠细节。
当然，本章我们讲述 Kafka 生产者的网络架构
一、引言
kafka生产端的组成主要由以下几方面构成：
- 生产端的初始化
- 元数据的更新
- 缓存池（BufferPool）机制
- 网络架构模型
- 消息发送
其中，我们 生产端的初始化、元数据的更新、缓存池（BufferPool）机制已经介绍完毕，今天我们来看看 网络架构模型
废话不多说，老司机开始发车
二、网络架构模型
从我们之前的讲解中，我们可以知道，生产端最重要的几个技术点：
- KafkaProducer：主要将消息发送至
RecordAccumulator并唤醒Sender - Sender：调用
NetworkClient将RecordAccumulator的消息发送至Broker - NetworkClient：
Kafka对Java NIO的封装
而正是它们几个组成了 Kafka 生产者的网络架构，其网络模型如下：
不难看出，我们 Kafka 生产者最终的网络架构也是使用的 Java NIO，和我们的 Netty 殊途同归。
至于 kafka 为什么不用 Netty 做通信组件，这个之间在 【Kafka从成神到升仙系列 三】你真的了解 Kafka 的元数据嘛 已经讲过，此处不再叙述，有兴趣的同学可以跳转阅读。
三、网络架构整体流程
上面我们了解了 Kafka 生产端的几个网络组件及其对应的关系
我们深入的看一下，这几个组件之间到底是如何进行数据的处理及业务的处理的
网络架构整体流程如下所示：
这里涉及的主要几个方法：
- KafkaProducer
- waitOnMetadata：等待更新元数据
- accumulator.append：消息发送到缓冲区
- sender.wakeup：唤醒
Sender线程
- Sender
- accumulator.ready：得到符合发送规定的节点
- metadata.requestUpdate：是否更新元数据
- remove any nodes：删除尚未建立连接的节点
- accumulator.drain：得到每个节点需要发送的消息批次
- createProduceRequests：组装成客户端请求
- client.send：调用
NetworkClient设置事件类型 - client.poll：调用
NetworkClient发送消息
- NetworkClient
- send：调用
Selector设置事件类型 - poll：调用
Selector发送消息
- send：调用
- Kafka-Selector
- send：设置事件类型
- poll：发送消息
可能大多数的小伙伴这个时候已经有点晕了，没关系，我们本篇文章就是解决你晕的问题的
我们会从 Producer 的源码一直会讲到 Selector 的源码并最终通过打日志的方式验证我们的猜想
戴好安全带，我们发车了
四、网络架构源码剖析
1、KafkaProducer
对于 KafkaProducer 来说，其最重要的功能就是将 record 发送至我们的 RecordAccumulator 中去
1.1 waitOnMetadata
这个方法相信看过上篇博客：【Kafka从成神到升仙系列 三】你真的了解 Kafka 的元数据嘛，已经有印象
对，没错，这个就是我们 kafka 在发送消息时，会优先请求 Broker 获取元数据信息，然后再去发送消息
具体细节的话，这里也不叙述了
总之：第一次发送消息时，这里会判断当前是否拿到了元数据。如果没有拿到元数据信息，这里会堵塞循环并唤醒 Sender 线程，让其帮忙更新元数据。
1.2 accumulator.append
这个其实我们这篇博客中也讲过：【Kafka从成神到升仙系列 二】生产者如何将消息放入到内存缓冲区
具体的细节如上，更多的细节可以参考上面那篇博客
1.3 sender.wakeup
当我们 **首次获取元数据 **或者 当前的 batch 满了 或者 一个新的 batch 创建了，我们都可以去唤醒我们的 Sender，让这个线程执行我们的业务。
- 首次获取元数据：让
Sender去更新元数据信息 - 当前的
batch满了 或者 一个新的batch创建：让Sender将batch发送至Broker
那这个 sender.wakeup 到底执行了什么呢，我们一起来看看其执行流程与执行代码
// 类 = KafkaProducer
sender.wakeup();
// 类 = Sender
public void wakeup()
this.client.wakeup();
// 类 = NetworkClient
public void wakeup()
this.selector.wakeup();
// 类 = Selector
public void wakeup()
this.nioselector.wakeup();
// 类 = WindowsSelectorImpl
public Selector wakeup()
// Java NIO 包里面的操作
这里可以看到，整体的调用流程和我们上面的 网络架构 是一样的，也侧面验证了我们上面的 网络架构 是正确的。
不难看出，sender.wakeup() 实际上是唤醒了 Java NIO 里面的 Selector，让其能够接受所有的 keys，从而完成通信的链接与发送。
2. Sender
Sender 线程的东西稍微有点多，但核心只有两个：
- 更新元数据消息
- 将消息发送至
Broker
当 Sender 线程启动时，会启动如下代码：
public void run()
while (running)
run(time.milliseconds());
void run(long now)
// 业务代码
从代码中不难看出，当我们启动 Sender 线程之后，Sender 线程会不断的轮询调用 run(long now) 该方法，执行其业务。
那 run(long now) 方法到底做了些什么呢，我们一起来看一下
2.1 accumulator.ready
- 遍历所有的
TopicPartition，获取每一个TopicPartition的Leader节点 - 弹出每一个
TopicPartition的第一个batch，校验该batch有没有符合发送的规定 - 如果该
batch符合了发送的规定后，将节点放至readyNodes中，标识该节点已经可以发送数据了
public ReadyCheckResult ready(Cluster cluster, long nowMs)
// 准备好的节点
Set<Node> readyNodes = new HashSet<>();
// 遍历所有的 TopicPartition
for (Map.Entry<TopicPartition, Deque<RecordBatch>> entry : this.batches.entrySet())
TopicPartition part = entry.getKey();
Deque<RecordBatch> deque = entry.getValue();
// 获取当前Partition的leader节点
Node leader = cluster.leaderFor(part);
if (leader == null)
unknownLeadersExist = true;
else if (!readyNodes.contains(leader) && !muted.contains(part))
synchronized (deque)
// 弹出每一个 TopicPartition 的第一个batch
RecordBatch batch = deque.peekFirst();
if (batch != null)
// bactch 满足 batch.size() 或者 时间达到 linger.ms、
boolean full = deque.size() > 1 || batch.records.isFull();
boolean expired = waitedTimeMs >= timeToWaitMs;
boolean sendable = full || expired || exhausted || closed || flushInProgress();
if (sendable && !backingOff)
// 将当前的节点添加至准备好的队列中
readyNodes.add(leader);
else
nextReadyCheckDelayMs = Math.min(timeLeftMs, nextReadyCheckDelayMs);
// 最终返回该节点（这里最重要的还是 Set<String> 也就是准备好的节点集合）
return new ReadyCheckResult(readyNodes, nextReadyCheckDelayMs, unknownLeadersExist);
public ReadyCheckResult(Set<Node> readyNodes, long nextReadyCheckDelayMs, boolean unknownLeadersExist)
this.readyNodes = readyNodes;
this.nextReadyCheckDelayMs = nextReadyCheckDelayMs;
this.unknownLeadersExist = unknownLeadersExist;
2.2 metadata.requestUpdate
- 如果发现有
TopicPartition没有 leader，那么这里就调用requestUpdate()方法更新 metadata
// 如果这个地方是 True，说明我们上面有的 TopicPartition 的 leader 节点为 null
if (result.unknownLeadersExist)
// 更新元数据
this.metadata.requestUpdate();
// 设置标记位为true,后续进行更新
public synchronized int requestUpdate()
this.needUpdate = true;
return this.version;
2.3 remove any nodes
- 遍历所有准备好的节点，利用
NetworkClient来判断改节点是不是已经准备完毕 - 如果该节点未准备完毕，则从
readyNodes中剔除 - 节点未准备完毕，会初始化链接该节点，便于下一次的消息发送
PS：这里可能会有同学对上面已经准备好了，下面为什么还有准备好的逻辑筛选有疑问
- 第一步筛选的是
TopicPartition对应的batch已经满足了发送的必要 - 第二步筛选的是
TopicPartition对应的Broker是否建立了链接，如果不是则初始化链接
// 遍历所有准备好的节点
Iterator<Node> iter = result.readyNodes.iterator();
long notReadyTimeout = Long.MAX_VALUE;
while (iter.hasNext())
Node node = iter.next();
// 利用 NetworkClient 来判断改节点是不是已经准备完毕
// 如果还未准备好，从准备好的队列中剔除掉
if (!this.client.ready(node, now))
iter.remove();
notReadyTimeout = Math.min(notReadyTimeout, this.client.connectionDelay(node, now));
// 判断节是否准备好发送
// 如果没有准备好发送，则会与该节点初始化链接，便于下一次的消息发送
public boolean ready(Node node, long now)
// 已经准备好
if (isReady(node, now))
return true;
// 与该节点的初始化
if (connectionStates.canConnect(node.idString(), now))
initiateConnect(node, now);
return false;
2.4 accumulator.drain
- 遍历所有准备好的
readyNodes，得到该Broker上所有的PartitionInfo信息，判断该Partition是否被处理中，如果没有在处理中则获取其对应的Deque<RecordBatch> - 弹出队列中的
First，判断其是否在backoff (没有重试过，或者重试了但是间隔已经达到了retryBackoffMs)且加上该 batch 的大小 < maxRequestSize，该batch符合规定 - 将该
batch放进readyRecordBatchList中，最终放进Map<node.id(), readyRecordBatchList>，这样我们一个Broker可以发送的batch就已经整理完毕。 - 最终我们得到
Map<Integer, List<RecordBatch>>，key代表当前已经连接好的Broker，value代表当前需要发送的batch
// 生成节点对应的batch消息
Map<Integer, List<RecordBatch>> batches = this.accumulator.drain(cluster,result.readyNodes,this.maxRequestSize, now);
public Map<Integer, List<RecordBatch>> drain(Cluster cluster, Set<Node> nodes,int maxSize,long now)
Map<Integer, List<RecordBatch>> batches = new HashMap<>();
// 遍历所有准备好的node节点
for (Node node : nodes)
int size = 0;
// 通过node节点获取其所有的Partition
List<PartitionInfo> parts = cluster.partitionsForNode(node.id());
// 存储该节点需要发送的Batch
List<RecordBatch> ready = new ArrayList<>();
int start = drainIndex = drainIndex % parts.size();
do
// 取Partition
PartitionInfo part = parts.get(drainIndex);
TopicPartition tp = new TopicPartition(part.topic(), part.partition());
// 当分区没有正在进行的批处理时
if (!muted.contains(tp))
// 获取该分区的所有的RecordBatch
Deque<RecordBatch> deque = getDeque(new TopicPartition(part.topic(), part.partition()));
if (deque != null)
synchronized (deque)
// 查看队列第一个
RecordBatch first = deque.peekFirst();
if (first != null)
// 判断其重试与时间
boolean backoff = first.attempts > 0 && first.lastAttemptMs + retryBackoffMs > now;
if (!backoff)
// 判断是否超越最大发送限制
if (size + first.records.sizeInBytes() > maxSize && !ready.isEmpty())
break;
else
// 取出队列第一个
RecordBatch batch = deque.pollFirst();
batch.records.close();
// 当前发送的大小累积
size += batch.records.sizeInBytes();
// 放入准备好的列表中
ready.add(batch);
batch.drainedMs = now;
this.drainIndex = (this.drainIndex + 1) % parts.size();
while (start != drainIndex);
// 将节点与准备好的batch列表对应
batches.put(node.id(), ready);
// 最终返回：所有准备好的节点与对应的batch列表
return batches;
2.5 createProduceRequests
- 遍历刚刚我们得到的
Map<node.id(), readyRecordBatchList，组装成客户端请求
List<ClientRequest> requests = createProduceRequests(batches, now);
// 组装客户端请求
private List<ClientRequest> createProduceRequests(Map<Integer, List<RecordBatch>> collated, long now)
List<ClientRequest> requests = new ArrayList<ClientRequest>(collated.size());
for (Map.Entry<Integer, List<RecordBatch>> entry : collated.entrySet())
requests.add(produceRequest(now, entry.getKey(), acks, requestTimeout, entry.getValue()));
return requests;
2.6 client.send
- 遍历每一个客户端请求并进行发送
PS：这里的发送是通过 KafkaClient 提供的接口，具体由 NetworkClient 实现，我们后面会讲
for (ClientRequest request : requests)
client.send(request, now);
2.7 client.poll
- 发送消息
PS：这里也同样是通过 KafkaClient 提供的接口，具体由 NetworkClient 实现，我们后面会讲
this.client.poll(pollTimeout, now);
3. NetworkClient
我们的 Sender 将 Producer 发送的消息进行 校验、筛选、组装，让我们的 NetworkClient 进一步的将消息发送
3.1 send
- 拿到当前客户端请求的
node，校验其是否有权限 - 如果有权限的话，我们设置下时间并添加到到
inFlightRequests，调用selector进行发送（这里提前剧透一下，send方法虽然叫发送，实际上并没有发送，只是注册了写事件，后面会讲到）
inFlightRequests 的作用：
- 缓存已经发出去但还没有收到响应的请求，保存对象的具体形式为
Map<NodeId，Deque<Request>> - 配置参数
max.in.flight.requests.per.connection，默认值为5，即每个连接最多只能缓存5个未收到响应的请求，超过这个数值之后便不能再往这个连接发送更多的请求了
public void send(ClientRequest request, long now)
// 拿到当前客户端请求的node
String nodeId = request.request().destination();
// 是否可以发送请求（我们前面已经校验过，一般情况下都能够发送）
if (!canSendRequest(nodeId))
throw new IllegalStateException("Attempt to send a request to node " + nodeId + " which is not ready.");
doSend(request, now);
private void doSend(ClientRequest request, long now)
// 设置时间
request.setSendTimeMs(now);
// 将当前请求添加到 inFlightRequests
this.inFlightRequests.add(request);
selector.send(request.request());
3.2 poll
- 判断当前需要更新元数据，如果需要则更新元数据
- 调用
selector的poll方法进行Socket IO的操作（这里也在后面会讲到） - 处理完成之后的操作
- 处理已经完成的 send
- 处理从 server 端接收到 Receive
- 处理连接失败那些连接
- 处理新建立的那些连接
- 处理超时的连接
- 如果回调的话，处理回调的信息
public List<ClientResponse> poll(long timeout, long now)
// 判断当前需要更新元数据，如果需要则更新元数据
long metadataTimeout = metadataUpdater.maybeUpdate(now);
// 调用 selector 的 poll 方法进行 Socket IO 的操作
this.selector.poll(Utils.min(timeout, metadataTimeout, requestTimeoutMs));
// 处理完成之后的操作
long updatedNow = this.time.milliseconds();
List<ClientResponse> responses = new ArrayList<>();
// 处理已经完成的 send（不需要 response 的 request,如 sendÿ以上是关于Kafka从成神到升仙系列 五面试官问我 Kafka 生产者的网络架构，我直接开始从源码背起.......的主要内容，如果未能解决你的问题，请参考以下文章
Spring从成神到升仙系列 一2023年再不会动态代理，就要被淘汰了
Spring从成神到升仙系列 四从源码分析 Spring 事务的来龙去脉
Spring从成神到升仙系列 三2023年再不会 AOP 源码，就要被淘汰了