netty-daxin-3(rpc远程调用)

发布时间:2023年12月20日

nettyRpc

ObjectEncoder 与 ObjectDecoder

  • ObjectEncoder继承自MessageToByteEncoder<Serializable>,它内部使用ByteBufOutputStream包装ByteBuf对象,然后使用CompactObjectOutputStream包装ByteBufOutputStream,也即:CompactObjectOutputStream—>ByteBufOutputStream—>ByteBuf,然后使用CompactObjectOutputStream将java对象写到ByteBuf中,并且写的过程中,是先写4个字节的占位符,它代表消息内容的长度,等写完了整个java对象的流之后,再把长度写到4个字节的占位符上。
  • ObjectDecoder继承自LengthFieldBasedFrameDecoder,显然,与它对应的编码器写消息的时候,就是按照长度字段来写的,因此解码须继承LengthFieldBasedFrameDecoder,然后拿到对象的字节流后,CompactObjectInputStream—>ByteBufInputStream—>ByteBuf
    在这里插入图片描述

jdk动态代理回顾

在这里插入图片描述

Rpc调用

有几个重要的点:

  1. 最好不要在eventLoop处理解码的ChannelHandler上处理业务,因为eventLoop内部只有1个线程在处理多个channel,如果处理业务的逻辑放在handler里面,相当于其它的channel就会受影响
  2. netty的调用都是异步的,我们需要在客户端发出rpc请求后,阻塞当前rpc调用的线程,然后在得到服务端的响应之后,再去唤醒当前调用rpc的线程。这需要对AQS、ReentrantLock、Condition内部的锁并发等待唤醒了解。

过程简析

服务端

在这里插入图片描述

客户端

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

文章来源:https://blog.csdn.net/qq_16992475/article/details/135038867
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。