Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑( 三 )


Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
然后就开始初始化网络连接了:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 

Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
这里连接的代码和平时写的 Java NIO 的代码是一样的
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
socket.setTcpNoDelay(true);注意,他这里有一句这个代码,这个默认值是 false,意思是它会把网络中的一些小的数据包收集起来,组合成一个大的数据包然后再发送出去 。
它认为如果网络中有大量小的数据包,会影响网络拥塞 。
所以这里,一定是要把它设置为 true 的 。因为有时候,数据包就是比较小,这里不帮我们发送,明细是不合适的 。
这里,建立网络连接,最终往 selector 上绑定了一个 OP_CONNECT 事件,和我们平时写的代码是一样的 。
最终这个方法返回了 false:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
那么回到主流程上,返回 false 之后,这些主机都会被移除 。
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
然后是步骤七,创建一个请求 。
最后执行到这里:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
点进去看,核心代码在这里:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
继续往里面看,核心代码在这里:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
点进去:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
再点进去,(当前位置:PlaintextTransportLayer)
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
这里,如果已经连接网络了,则移除 OP_CONNECT 事件,并且增加 OP_READ 事件,这样的话,就可以读取到 服务端发送回来的响应了 。
到这里位置,第一遍就建立好了网络连接 。
六、准备发送消息刚刚我们第一遍执行,建立好了网络连接,现在开始第二次执行
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
这里网络已经准备好了,所以 if 的方法不执行,节点也不会被移除了
这个时候是可以合并批次的,因为这个 nodes 不为空
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
然后创建一个请求,并且发送这个请求:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
点进去:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
在点进去 send 方法里,这里有一个很重要的操作,绑定了 OP_WRITE 事件
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 

Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
绑定了 OP_WRITE 事件,才能把数据发送出去!!
现在我们再退回到 这个方法:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
点到 poll 方法里来:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
然后这里会从 selector 上拿到 SelectionKey,如果是写事件:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 

Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
点到 send 方法里来:
Kafka 的网络通信设计,竟然只用 20 行就实现了粘包拆包逻辑

文章插图
 
把消息写出去,并且移除 OP_WRITE 事件 。
到此为止,消息终于发送出去了 。七、获取服务端的响应,拆包和粘包处理我们可以想到,客户端发送出去的肯定是多个请求,那么服务端返回的也是多个请求,那客户端如何从响应中解析出这多个请求呢?这就是拆包处理 。
比如,服务端返回的响应是这样的:
响应成功响应失败
我们要拆分成:
响应成功
响应失败


推荐阅读