关于RPC中序列化的一些思考

前言

最近在思考关于RPC的通信效率的相关问题,首先先放张图:ns/op是纳秒/操作数

全方位评测:Protobuf性能到底有没有比JSON快5倍?_2.jpg

从时间来看,Protobuf要更快,原因是它直接采用字节流传输.大多数序列化都是通过反射获取对象,然后将对象转为JSON字符串,再转为字节流发送,但是在Java中的反射是比较耗时的,印象中应该是ms级别的消耗.

思考

所以我就在想能不能通过将一个对象中的所有属性直接采用byte数组存储在内存上,当需要发送数据的时候,直接将读取发送就可以了.但是这样的想法虽然在传输速度上有显著的提升,可是并不易扩展,当一个对象的属性占用的字节长度随意改变的时候,会受到很大的限制.打个比方,本来存储"bery",需要一个char[4],也就是byte[8],但是当这个String改变的时候,byte数组的长度也会发生改变.

所以我想着可以在属性上定义一个注解,通过注解设置定长的方式,限制它的长度,当这个属性的指向长度超出预期时,抛出异常.

这样限制长度主要是为了让一个对象的byte长度一定,这样我传输对象的时候,主需要把这个byte数组传输给对方即可,而在内存上,对于byte数组进行压缩操作,既然一个属性占用固定的byte数组,直接压缩进多个内存块(一个内存块占用4KB)就可以.

不过想是这么想,当出现一个类非常复杂时就很难搞,比如说一个类继承自一个类,再往上还有类,也就是爷爷->爸爸->儿子->孙子,那么孙子的存储就会遇到很大的问题,但从我最近的项目经验来讲,一般一个entity实体都是继承自Object类型,vo的继承会多一些,而对于一个对象中有List属性的实体就更少了.所以简单粗暴的给这个传输加个继承限制可能也没毛病.

目前还在一点一点的实现,本博客只是记录以及分享自己的想法,欢迎大家提出问题与指正.

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值