Kafka源码分析（十一）——Producer：NIO通讯——读响应拆包和粘包

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

上一章，我讲解了Kafka发送请求时，对拆包问题的处理流程。Kafka客户端会与每个Broker都建立一个TCP长连接，每一个请求都会发送完后才会发送下一个请求，所以一般不存在粘包问题。

但是，当Kafka客户端读取Broker的响应时就不一样了，存在两种情况：

1. 读取的响应中，包含了多个请求的完整响应，也就是出现了 粘包 ；
2. 读取的响应中，只包含了一个请求的部分响应，此时就需要多次读取，将多次读取的结果进行合并，也就是出现了 拆包 。

本章，我先来讲解Kafka客户端对 OP_READ 事件的处理流程，然后对读响应的拆包和粘包问题进行分析。

一、读响应

我们先来回顾下Kafka客户端的底层是如何读取响应数据的。本质还是通过Selector.poll()方法，这块大家应该已经很熟悉了：

    // Selector.java
    
    private final Map<KafkaChannel, Deque<NetworkReceive>> stagedReceives;    // 按照Broker维度缓存响应请求
    private final List<NetworkReceive> completedReceives;                    // 保存每个Broker的最近一个响应请求
    public void poll(long timeout) throws IOException {
        //...
    
        // 1.遍历SelectionKey进行处理
        if (readyKeys > 0 || !immediatelyConnectedKeys.isEmpty()) {
            pollSelectionKeys(this.nioSelector.selectedKeys(), false, endSelect);
            pollSelectionKeys(immediatelyConnectedKeys, true, endSelect);
        }
        // 2.将最近一个读取完成的响应，添加到响应列表completedReceives
        addToCompletedReceives();
    }
    
    private void pollSelectionKeys(Iterable<SelectionKey> selectionKeys,
                                   boolean isImmediatelyConnected,
                                   long currentTimeNanos) {
        // ...
        // Channel中有OP_READ事件发生，且不存在已经读取完毕的响应
        if (channel.ready() && key.isReadable() && !hasStagedReceive(channel)) {
            NetworkReceive networkReceive;    //用于暂存读取的数据
            // 循环从Channel读取数据，networkReceive!=null，表示一个完整