为什么粘包是个问题TCP 是面向流的协议只有字节流概念没有消息边界。Producer 连续发三个请求接收方一次 read 可能只读到第一个的一半半包也可能把三个全读进来粘包甚至是前两个完整加第三个的一半。如果应用层不做边界处理收到的数据根本没法解析。Kafka 作为一个二进制协议消息体里可能包含任意字节包括换行符不能用分隔符消息大小从几十字节到几 MB 不等不能用固定长度。Kafka 选择了工业级二进制协议的标准方案长度前缀帧格式。01 长度前缀方案4 字节界定消息边界Kafka 每条消息前面放 4 字节 int32大端表示后续消息体的字节数。读取时先读 4 字节得到长度 N再读满 N 字节就是一条完整消息。为什么不用其他方案固定分隔符\n消息体不能含分隔符需转义二进制数据不适用逐字节扫描性能差固定长度消息大小差异大时浪费空间无法支持变长消息扩展困难长度前缀支持任意长度二进制数据读取效率高先读长度再批量读消息损坏只影响当前条不扩散这套方案不是 Kafka 独创——Thrift、gRPC、Protobuf 帧都用长度前缀。Kafka 的选择是经过验证的最优解。02 NetworkReceive累积不完整数据KafkaChannel 每个连接维护一个 NetworkReceive 对象负责处理读取过程中的半包和粘包。NetworkReceive 内部结构sizeByteBuffer4字节存储消息长度size.remaining()0 表示长度已读全bufferByteBuffer消息体按 size 分配buffer.remaining()0 表示消息已读全sourceString来源节点 ID用于匹配 InFlight 请求done()size 和 buffer 都读全才返回 true读取流程Selector.poll() 中 OP_READ 就绪时调用 channel.read()数据进入 NetworkReceive.readFrom()。先读 sizesize 未满则累积等下一轮size 读全后按长度分配 buffer再读 bodybody 未满也累积。done()true 时消息完整加入 completedReceives 交给上层解析同时创建新的 NetworkReceive 等下一条。粘包天然支持一条解析完剩余字节自动作为下一条的 size 继续读无需特殊处理。半包自动累积size 或 body 未读全时保留在 NetworkReceive不丢数据下一轮 poll 继续读。03 Kafka 协议帧格式与请求响应匹配请求帧和响应帧结构略有不同但都用 4 字节长度前缀。请求帧结构size(4B) api_key(2B) api_version(2B) correlation_id(4B) client_id(可变) request_body(可变)。api_key 标识请求类型Produce0、Fetch1、Metadata3api_version 支持协议演进correlation_id 是请求唯一标识。响应帧结构size(4B) correlation_id(4B) response_body(可变)。响应没有 api_key/api_version/client_id靠 correlation_id 匹配对应的请求。匹配流程发送请求时分配 correlationId 并加入 InFlightRequests收到响应后取出 correlationId从对应节点的 InFlight 队首取出请求触发 callback成功则 batch.done() 完成 Future失败则可重试的放回队首、不可重试的抛异常InFlight 计数减 1可以发新请求。关键设计细节大端字节序size 用 int32 大端网络字节序跨平台兼容最大消息限制size 超过 max.request.size默认1MB直接拒绝防止 OOM内存池化body ByteBuffer 从 ByteBufferPool 分配解析完归还复用每连接独立 receive每个 KafkaChannel 有自己的 NetworkReceive互不干扰错误隔离一条消息长度异常只影响当前连接不会污染其他连接零拷贝友好body 可直接用 FileChannel.transferTo 写入磁盘Broker 端写在最后Kafka 处理粘包的方案看似简单——4 字节长度前缀但背后是一整套完整的设计NetworkReceive 的半包累积、粘包自动续读、correlationId 的请求响应匹配、ByteBufferPool 的内存池化。简单的接口背后是严谨的工程实现。这也是读源码的价值不是看用了什么复杂算法而是看怎么用简单的机制把边界情况处理干净。下一篇看响应处理的完整流程——ProduceResponse 怎么解析、怎么触发 callback、失败怎么重试。