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
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
最新文章