首页 > 代码库 > ? Protocol Buffers的应用与分析

? Protocol Buffers的应用与分析

1  Protocol Buffers的介绍

Protocol Buffers是一种用于序列化结构化数据的机制,它具有灵活、高效、自动化的特点。类似于XML,但是比XML更小巧、快捷、简单。在Google 几乎所有它内部的RPC协议和文件格式都是采用PB。
PB具有以下特点:

  1. 平台无关、语言无关
  2. 高性能 比XML块20-100倍
  3. 体积小 比XML小3-10倍
  4. 使用简单
  5. 兼容性好

在这里,我做了个小实验,将一个29230KB的自定义格式的文本数据转换成PB和XML:

PB XML
转换后的大小 21011KB 43202KB
解析时间(100次循环) 18610ms 169251ms
完成解析所写代码行数 1行 50行

与官方说法的差距,主要可能是因为应用场景不同,我的测试数据中字段比较长

表1:PB与XML的实验比较

可见,PB作为一种轻量级的数据协议,在时间、空间上都有一定的优势。

2  Protocol Buffers的简单应用

2.1  创建流程

2.1.1  定义一个.proto文件

新建一个文件,命名为addressbook.proto,内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
package tutorial; //命名空间
 
option java_package = "com.example.tutorial" ; //生成文件的包名
option java_outer_classname = "AddressBookProtos" ; //类名
 
message Person { //要描述的结构化数据
 
     required string name = 1 ; //required表示这个字段不能为空
     required int32 id = 2 ; //等号后面的内容为数字别名
     optional string email = 3 ; //optional表示可以为空
 
     PhoneNumber { //内部message
         required string number = 1 ;
         optional int32 type = 2 ;
     }
 
     repeated PhoneNumber phone = 4
}
 
message AddressBook {
     repeated Person person = 1 ; //是个集合
}

对以上内容的一点解释:

  • PB所支持的元类型数据请参考:PB元类型数据
  • 修饰符required:这个修饰符应该谨慎使用,滥用会导致后续的修改容易出现兼容性问题;
  • 修饰符optional:对于常出现的属性,为节省空间应该取1-16的别名;
  • PB是以key-value的形式来将结构化数据序列化的。它采用了将等号后的数字别名以及属性的类型用varints编码成一个数字,来作为key。

2.1.2  使用PB编译器

输入:protoc      -I=$SRC_DIR –java_out=$DST_DIR $SRC_DIR/addressbook.proto
其中    -I指定.proto文件所在目录
–java_out指定生成java文件所在的目录

2.1.3  使用PB的API来写入和读取messages

经过以上步骤,会在指定的$DST_DIR目录下生成一个AddressBookProtos.java的类。在maven中引入protobuf-java这个依赖后,利用这个类,便能序列化/反序列化数据了。
生成的代码结构如下:

1
2
3
4
5
6
7
class AddressBookProtos{
     class Person{
         class PhoneNumber{ class Builder{} }
         class Builder{}
     }
     class AddressBook{ class Builder{} }
}

可以看到Person、PhoneNumber、AddressBook这些内部类则对应了所定义的那些message。

2.2  序列化数据及分析

通过阅读代码可以看到,以上三个类的成员变量都是private类型的,并且,只提供了getter方法,而没有提供setter方法去为数据变量赋值。
PB利用了内部类可以访问到外部类中私有成员变量的特性。对外部类的任何赋值操作都需要通过Builder内部类来进行。Builder中有一个指向外部类的引用(名为result),当赋值完成,调用Builder的build()方法时,会把这个对象返回,同时使result指向null。
PB通过这样一种方式保证了数据安全性,一旦数据构建完毕,将无法再对其进行修改。
拿PhoneNumber这个类来说,对成员变量number、type赋值,需要以如下方式来进行:

1
2
3
4
5
6
7
PhoneNumber.Builder builder = PhoneNumber.newBuilder();
 
//调用setter赋值,setter返回了this,所以可以链式表述
builder.setNumber( "111" ).setType( 1 );
     
//赋值完成后,调用Builder的build方法,将返回PhoneNumber对象
PhoneNumber phoneNumber = builder.build();

构建完成后,可以调用writeTo方法,将数据写入数据流中。

2.3  反序列化及分析

一行代码便能完成反序列化:

1
AddressBook  list = AddressBook .parseFrom(inputStream或buffer);

背后PB做了很多事情:

  1. 根据inputStream或者buffer去构造一个CodedInputStream;
  2. 然后使用生成代码中的mergeFrom方法,去解析二进制数据:
    首先调用CodedInputStream的readTag,也就是从中取得key值(int类型),然后通过swtich块来往对象中赋值(PB采用了Base 128 Varints的方式来编码这个数字,后面会介绍这种方式的)。
  3. 将数据解析完成后,会调用build()方法,将构建好的对象返回。

3  message的编码特点

PB之所以解析速度快、所占体积小,很大程度上是由它序列化的编码特点来决定的。

3.1 Base 128 Varints

PB采用了Base 128 Varints来变长编码整数:

  1. 变长编码的整数,它可能包含多个byte,对于每个byte的8位,其中后7位表示数值,最高的一位表示是否还有还有另一个byte,0表示没有,1表示有;
  2. 越前面的byte表示数值的低位,越后面的byte表示数值的高位;

例子:
300   varints  编码为:1010 1100 0000 0010
解释如下:
300的2进制编码为:0001 0010 1100
按照刚才的规则,高低位颠倒,截取最后的7为放在第一个byte,则第一byte为1010 1100(其中最高位1表示,后续还有byte);接着剩下的内容放到第二个byte,为0000 0010(其中最高位0表示,后续无byte,这个数到这里截止了)。
于是,合在一起为 1010 1100 0000 0010;

3.2 Key-Value

如前所述,PB的message是一系列的key-value对,在二进制数据中,使用varints数字(包含了别名以及属性类型信息)来作为key,进而通过由PB编译器生成的代码来构造以及解析数据。
PB将 key编码成下面的结构: 
X YYYY ZZZ
其中:最高位X表示是否还有后续的byte来编码数字别名;YYYY用于编码别名,定义了多余16个属性,则需要用到额外的byte,所以出现频率高的字段应当取1-16的别名);ZZZ表示这个字段的类型,PB支持的属性的对应规则如下表:

Type Meaning Used For
0 Varint int32, int64, uint32, uint64, sint32,sint64, bool, enum
1 64-bit fixed64, sfixed64, double
2 Length-delimited string, bytes, embedded messages,packed repeated fields
3 Start group groups (deprecated)
4 End group groups (deprecated)
5 32-bit fixed32, sfixed32, floa

表2:PB 属性对应规则
例子:
required int32 a=1;  在应用中给a赋值150   ,序列化后08 96 01

  • 08代表的是key 0 0001 000, 最高位为0,表示这个key为一个byte,中间四位表示a的数字别名,最后三位表示a的属性类型;
  • 96 01代表的是value,二进制为:1001 0110 0000 0001
    → 001 0110    000 0001(去掉最高位)
    → 22              +  1*2^7 = 150

3.3 Zig-Zag

采用varints的方式编码有符号的整数,效率比较差,因为负数的最高位是1,这样就导致了情况类似于编码一个很大的数。

为了解决这个问题,Protocol Buffers定义了sint32/sint64属性,他们采用了“之字形”(ZigZag)编码的方式,将负数编码成正数,交替进行。看了下表就很好理解了:

Signed Original Encoded As
0 0
-1 1
1 2
-2 3
2147483647 4294967294
2147483648 4294967295

表3:Zig-Zag编码规则
利用这个方式,可以有效地节省存储空间,也能提高解析效率。

了解了以上内容,对于其他数据类型的编码,也是很好理解的,大家可以参考官方文档,这里不做详述。

4 其他

官方文档中,有提到PB提供了RPC的接口,但是没有提供具体实现。当在的.proto文件中,加入如下定义:

1
2
3
service XXX {
     rpc MMM(request) returns(response);
}

PB便会为你生成一个代表这个服务的XXX虚类,通过实现这个类中的abstract MMM方法,以及提供RpcChannel的实现,你便可以利用Protocol Buffers实现你的RPC了。

第三方的RPC实现大家可以参考ThirdPartyRPC

在这里,我利用了第三方实现protobuf-socket-rpc,写了一个小例子,有兴趣的可以看看。如下:Protocol buffer的rpc例子

5 小结

PB具有跨平台、解析速度快、序列化数据体积小、扩展性高、使用简单的特点。但是我们也可以看到,相比于XML,PB的数据,并不是自然可读的;同时它生成的代码不是纯pojo,对于代码有一定的侵入性。在你的项目中,如果对于以上缺点要求并不高,可以尝试着使用PB。