Protoc Buffer 优化传输大小的一个细节

  Protoc Buffer 是我们比较常用的序列化框架,Protocol Buffer 序列化后的占空间小,传输高效,可以在不同编程语言以及平台之间传输。今天这篇文章主要介绍 Protocol Buffer 使用 VarInt32 减少序列化后的数据大小。

  VarInt32 编码

  VarInt32 (vary int 32),即:长度可变的 32 为整型类型。一般来说,int 类型的长度固定为 32 字节。但 VarInt32 类型的数据长度是不固定的,VarInt32 中每个字节的最高位有特殊的含义。如果最高位为 1 代表下一个字节也是该数字的一部分。因此,表示一个整型数字最少用 1 个字节,最多用 5 个字节表示。如果某个系统中大部分数字需要 = 4 字节才能表示,那其实并不适合用 VarInt32 来编码。下面以一个例子解释 VarInt32 的编码方式:

  以129为例,它的二进制为10000001。由于每个字节最高位用于特殊标记,因此只能有7位存储数据。第一个字节存储最后7位(0000001),但并没有存下所有的比特,因此最高位置位1,剩下的部分用后续字节表示。所以,第一个字节为:10000001第二个字节只存储一个比特位即可,因此最高位为0,所以,第二个字节为:00000001这样,我们就不必用4字节的整型存储129,可以节省存储空间

  在 Protoc buffer 中,每一个 ProtoBuf 对象都有一个方法public void writeDelimitedTo(final OutputStream output),该方法将 ProtoBuf 对象序列化后的长度以及序列化数据本身写入到输出流 output 中。多个对象调用该方法可以将序列化后的数据写入到同一个输出流。由于每次写入都有长度,所以反序列化时先解析长度,在读取对应长度的字节数据,即可解析出每个对象。该方法中对序列化后长度的编码便使用 VarInt32,因为一个 Protobuf 对象序列化后的长度不会太大,因此使用 VarInt32 编码能够有效的节省存储空间。接下来我们看下 Protoc Buffer 中如何实现 VarInt32 编码,跟进 writeDelimitedTo 方法,可以看到 VarInt32 编码的源码如下:

  

Protoc Buffer 优化传输大小的一个细节

 

  该方法对 int 类型的值进行 VarInt32 编码,可以验证最多 5 个字节即可完成编码。

  VarInt32 解码

  理解了编码后,解码就没什么可说的了。就是从输入字节流中,读取一个字节判断最高位,将真实数据位拼接成最终的数字即可。Hadoop RPC 中使用了 Protoc Buffer 作为数据序列化框架。其中,Hadoop 针对 writeDelimitedTo 方法实现了对 VarInt32 的解码。源码如下:

  

Protoc Buffer 优化传输大小的一个细节

 

  在 Hadoop 源码中并没有使用循环去解码,而是使用多个 if 条件判断,根据 tmp 的正负号来判断最高位是否是 1。如果读取的该数字用了 5 个字节编码,当读到了第 5 个字节,理论上 tmp 应该大于 0 。但是如果 tmp 小于 0 ,说明编码格式有问题。在 Hadoop 源码中程序会继续往下读,最多再向下读 5 个字节且丢掉最高位仍然 0 的字节。如果在该过程某个字节最高位为 0 ,便停止读取直接返回。这个处理逻辑在其他框架源码中也有出现。

  看完 Hadoop 的源码,我们在看看 Protoc Buffer 自己提供的解析源码:

  

Protoc Buffer 优化传输大小的一个细节

 

  可以看到 Protoc Buffer 自己提供的解码方式与 Hadoop 是一样的,包括遇到错误的编码时候的异常处理方式也是一样的。

  小结

  本篇文章主要介绍了 VarInt32 编解码,VarInt32 表示一个整型数字最少用 1 个字节, 最多用 5 个字节。所以在传输数字大部分都比较小的场景下适合使用。当然,我们也可以用 VarInt64 来表示长整型的数字。 在介绍 VarInt32 的同时我们也看到了 ProtoBuf 和 Hadoop 这样的框架在传输数据的优化上不放过任何一个细节,值得我们学习。

  

上一篇:使用 go protoc --go_out 输出的 *.pb.go文件时报 undefined: proto.ProtoPackageIsVersion3


下一篇:【windows】安装tensorflow中的delf深度图像检索模块