Google Protocol Buffer 的使用和原理.docx
- 文档编号:4454565
- 上传时间:2022-12-01
- 格式:DOCX
- 页数:17
- 大小:119.53KB
Google Protocol Buffer 的使用和原理.docx
《Google Protocol Buffer 的使用和原理.docx》由会员分享,可在线阅读,更多相关《Google Protocol Buffer 的使用和原理.docx(17页珍藏版)》请在冰豆网上搜索。
GoogleProtocolBuffer的使用和原理
简介
什么是GoogleProtocolBuffer?
假如您在网上搜索,应该会得到类似这样的文字介绍:
GoogleProtocolBuffer(简称Protobuf)是Google公司内部的混合语言数据标准,目前已经正在使用的有超过48,162种报文格式定义和超过12,183个.proto文件。
他们用于RPC系统和持续数据存储系统。
ProtocolBuffers是一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,或者说序列化。
它很适合做数据存储或RPC数据交换格式。
可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。
目前提供了C++、Java、Python三种语言的API。
或许您和我一样,在第一次看完这些介绍后还是不明白Protobuf究竟是什么,那么我想一个简单的例子应该比较有助于理解它。
一个简单的例子
安装GoogleProtocolBuffer
在网站 Protobuf的源代码。
然后解压编译安装便可以使用它了。
安装步骤如下所示:
tar-xzfprotobuf-2.1.0.tar.gz
cdprotobuf-2.1.0
./configure--prefix=$INSTALL_DIR
make
makecheck
makeinstall
关于简单例子的描述
我打算使用Protobuf和C++开发一个十分简单的例子程序。
该程序由两部分组成。
第一部分被称为Writer,第二部分叫做Reader。
Writer负责将一些结构化的数据写入一个磁盘文件,Reader则负责从该磁盘文件中读取结构化数据并打印到屏幕上。
准备用于演示的结构化数据是HelloWorld,它包含两个基本数据:
∙ID,为一个整数类型的数据
∙Str,这是一个字符串
书写.proto文件
首先我们需要编写一个proto文件,定义我们程序中需要处理的结构化数据,在protobuf的术语中,结构化数据被称为Message。
proto文件非常类似java或者C语言的数据定义。
代码清单1显示了例子应用中的proto文件内容。
清单1.proto文件
packagelm;
messagehelloworld
{
requiredint32id=1;//ID
requiredstringstr=2;//str
optionalint32opt=3;//optionalfield
}
一个比较好的习惯是认真对待proto文件的文件名。
比如将命名规则定于如下:
packageName.MessageName.proto
在上例中,package名字叫做lm,定义了一个消息helloworld,该消息有三个成员,类型为int32的id,另一个为类型为string的成员str。
opt是一个可选的成员,即消息中可以不包含该成员。
编译.proto文件
写好proto文件之后就可以用Protobuf编译器将该文件编译成目标语言了。
本例中我们将使用C++。
假设您的proto文件存放在$SRC_DIR下面,您也想把生成的文件放在同一个目录下,则可以使用如下命令:
protoc-I=$SRC_DIR--cpp_out=$DST_DIR$SRC_DIR/addressbook.proto
命令将生成两个文件:
lm.helloworld.pb.h,定义了C++类的头文件
lm.helloworld.pb.cc,C++类的实现文件
在生成的头文件中,定义了一个C++类helloworld,后面的Writer和Reader将使用这个类来对消息进行操作。
诸如对消息的成员进行赋值,将消息序列化等等都有相应的方法。
编写writer和Reader
如前所述,Writer将把一个结构化数据写入磁盘,以便其他人来读取。
假如我们不使用Protobuf,其实也有许多的选择。
一个可能的方法是将数据转换为字符串,然后将字符串写入磁盘。
转换为字符串的方法可以使用sprintf(),这非常简单。
数字123可以变成字符串”123”。
这样做似乎没有什么不妥,但是仔细考虑一下就会发现,这样的做法对写Reader的那个人的要求比较高,Reader的作者必须了Writer的细节。
比如”123”可以是单个数字123,但也可以是三个数字1,2和3,等等。
这么说来,我们还必须让Writer定义一种分隔符一样的字符,以便Reader可以正确读取。
但分隔符也许还会引起其他的什么问题。
最后我们发现一个简单的Helloworld也需要写许多处理消息格式的代码。
如果使用Protobuf,那么这些细节就可以不需要应用程序来考虑了。
使用Protobuf,Writer的工作很简单,需要处理的结构化数据由.proto文件描述,经过上一节中的编译过程后,该数据化结构对应了一个C++的类,并定义在lm.helloworld.pb.h中。
对于本例,类名为lm:
:
helloworld。
Writer需要include该头文件,然后便可以使用这个类了。
现在,在Writer代码中,将要存入磁盘的结构化数据由一个lm:
:
helloworld类的对象表示,它提供了一系列的get/set函数用来修改和读取结构化数据中的数据成员,或者叫field。
当我们需要将该结构化数据保存到磁盘上时,类lm:
:
helloworld已经提供相应的方法来把一个复杂的数据变成一个字节序列,我们可以将这个字节序列写入磁盘。
对于想要读取这个数据的程序来说,也只需要使用类lm:
:
helloworld的相应反序列化方法来将这个字节序列重新转换会结构化数据。
这同我们开始时那个“123”的想法类似,不过Protobuf想的远远比我们那个粗糙的字符串转换要全面,因此,我们不如放心将这类事情交给Protobuf吧。
程序清单2演示了Writer的主要代码,您一定会觉得很简单吧?
清单2.Writer的主要代码
#include"lm.helloworld.pb.h"
…
intmain(void)
{
lm:
:
helloworldmsg1;
msg1.set_id(101);
msg1.set_str(“hello”);
//Writethenewaddressbookbacktodisk.
fstreamoutput("./log",ios:
:
out|ios:
:
trunc|ios:
:
binary);
if(!
msg1.SerializeToOstream(&output)){
cerr<<"Failedtowritemsg."< return-1; } return0; } Msg1是一个helloworld类的对象,set_id()用来设置id的值。 SerializeToOstream将对象序列化后写入一个fstream流。 代码清单3列出了reader的主要代码。 清单3.Reader #include"lm.helloworld.pb.h" … voidListMsg(constlm: : helloworld&msg){ cout< cout< } intmain(intargc,char*argv[]){ lm: : helloworldmsg1; { fstreaminput("./log",ios: : in|ios: : binary); if(! msg1.ParseFromIstream(&input)){ cerr<<"Failedtoparseaddressbook."< return-1; } } ListMsg(msg1); … } 同样,Reader声明类helloworld的对象msg1,然后利用ParseFromIstream从一个fstream流中读取信息并反序列化。 此后,ListMsg中采用get方法读取消息的内部信息,并进行打印输出操作。 运行结果 运行Writer和Reader的结果如下: >writer >reader 101 Hello Reader读取文件log中的序列化信息并打印到屏幕上。 本文中所有的例子代码都可以在附件中下载。 您可以亲身体验一下。 这个例子本身并无意义,但只要您稍加修改就可以将它变成更加有用的程序。 比如将磁盘替换为网络socket,那么就可以实现基于网络的数据交换任务。 而存储和交换正是Protobuf最有效的应用领域。 和其他类似技术的比较 看完这个简单的例子之后,希望您已经能理解Protobuf能做什么了,那么您可能会说,世上还有很多其他的类似技术啊,比如XML,JSON,Thrift等等。 和他们相比,Protobuf有什么不同呢? 简单说来Protobuf的主要优点就是: 简单,快。 这有测试为证,项目thrift-protobuf-compare比较了这些类似的技术,图1显示了该项目的一项测试结果,TotalTime. 图1.性能测试结果 TotalTime指一个对象操作的整个时间,包括创建对象,将对象序列化为内存中的字节序列,然后再反序列化的整个过程。 从测试结果可以看到Protobuf的成绩很好,感兴趣的读者可以自行到网站 Protobuf的优点 Protobuf有如XML,不过它更小、更快、也更简单。 你可以定义自己的数据结构,然后使用代码生成器生成的代码来读写这个数据结构。 你甚至可以在无需重新部署程序的情况下更新数据结构。 只需使用Protobuf对数据结构进行一次描述,即可利用各种不同语言或从各种不同数据流中对你的结构化数据轻松读写。 它有一个非常棒的特性,即“向后”兼容性好,人们不必破坏已部署的、依靠“老”数据格式的程序就可以对数据结构进行升级。 这样您的程序就可以不必担心因为消息结构的改变而造成的大规模的代码重构或者迁移的问题。 因为添加新的消息中的field并不会引起已经发布的程序的任何改变。 Protobuf语义更清晰,无需类似XML解析器的东西(因为Protobuf编译器会将.proto文件编译生成对应的数据访问类以对Protobuf数据进行序列化、反序列化操作)。 使用Protobuf无需学习复杂的文档对象模型,Protobuf的编程模式比较友好,简单易学,同时它拥有良好的文档和示例,对于喜欢简单事物的人们而言,Protobuf比其他的技术更加有吸引力。 Protobuf的不足 Protbuf与XML相比也有不足之处。 它功能简单,无法用来表示复杂的概念。 XML已经成为多种行业标准的编写工具,Protobuf只是Google公司内部使用的工具,在通用性上还差很多。 由于文本并不适合用来描述数据结构,所以Protobuf也不适合用来对基于文本的标记文档(如HTML)建模。 另外,由于XML具有某种程度上的自解释性,它可以被人直接读取编辑,在这一点上Protobuf不行,它以二进制的方式存储,除非你有.proto定义,否则你没法直接读出Protobuf的任何内容【2】。 高级应用话题 更复杂的Message 到这里为止,我们只给出了一个简单的没有任何用处的例子。 在实际应用中,人们往往需要定义更加复杂的Message。 我们用“复杂”这个词,不仅仅是指从个数上说有更多的fields或者更多类型的fields,而是指更加复杂的数据结构: 嵌套Message 嵌套是一个神奇的概念,一旦拥有嵌套能力,消息的表达能力就会非常强大。 代码清单4给出一个嵌套Message的例子。 清单4.嵌套Message的例子 messagePerson{ requiredstringname=1; requiredint32id=2;//UniqueIDnumberforthisperson. optionalstringemail=3; enumPhoneType{ MOBILE=0; HOME=1; WORK=2; } messagePhoneNumber{ requiredstringnumber=1; optionalPhoneTypetype=2[default=HOME]; } repeatedPhoneNumberphone=4; } 在MessagePerson中,定义了嵌套消息PhoneNumber,并用来定义Person消息中的phone域。 这使得人们可以定义更加复杂的数据结构。 4.1.2ImportMessage 在一个.proto文件中,还可以用Import关键字引入在其他.proto文件中定义的消息,这可以称做ImportMessage,或者DependencyMessage。 比如下例: 清单5.代码 importcommon.header; messageyouMsg{ requiredcommon.info_headerheader=1; requiredstringyouPrivateData=2; } 其中,common.info_header定义在common.header包内。 ImportMessage的用处主要在于提供了方便的代码管理机制,类似C语言中的头文件。 您可以将一些公用的Message定义在一个package中,然后在别的.proto文件中引入该package,进而使用其中的消息定义。 GoogleProtocolBuffer可以很好地支持嵌套Message和引入Message,从而让定义复杂的数据结构的工作变得非常轻松愉快。 动态编译 一般情况下,使用Protobuf的人们都会先写好.proto文件,再用Protobuf编译器生成目标语言所需要的源代码文件。 将这些生成的代码和应用程序一起编译。 可是在某且情况下,人们无法预先知道.proto文件,他们需要动态处理一些未知的.proto文件。 比如一个通用的消息转发中间件,它不可能预知需要处理怎样的消息。 这需要动态编译.proto文件,并使用其中的Message。 Protobuf提供了 google: : protobuf: : compiler包来完成动态编译的功能。 主要的类叫做importer,定义在importer.h中。 使用Importer非常简单,下图展示了与Import和其它几个重要的类的关系。 图2.Importer类 Import类对象中包含三个主要的对象,分别为处理错误的MultiFileErrorCollector类,定义.proto文件源目录的SourceTree类。 下面还是通过实例说明这些类的关系和使用吧。 对于给定的proto文件,比如lm.helloworld.proto,在程序中动态编译它只需要很少的一些代码。 如代码清单6所示。 清单6.代码 google: : protobuf: : compiler: : MultiFileErrorCollectorerrorCollector; google: : protobuf: : compiler: : DiskSourceTreesourceTree; google: : protobuf: : compiler: : Importerimporter(&sourceTree,&errorCollector); sourceTree.MapPath("",protosrc); importer.import(“lm.helloworld.proto”); 首先构造一个importer对象。 构造函数需要两个入口参数,一个是sourceTree对象,该对象指定了存放.proto文件的源目录。 第二个参数是一个errorcollector对象,该对象有一个AddError方法,用来处理解析.proto文件时遇到的语法错误。 之后,需要动态编译一个.proto文件时,只需调用importer对象的import方法。 非常简单。 那么我们如何使用动态编译后的Message呢? 我们需要首先了解几个其他的类 Packagegoogle: : protobuf: : compiler中提供了以下几个类,用来表示一个.proto文件中定义的message,以及Message中的field,如图所示。 图3.各个Compiler类之间的关系 类FileDescriptor表示一个编译后的.proto文件;类Descriptor对应该文件中的一个Message;类FieldDescriptor描述一个Message中的一个具体Field。 比如编译完lm.helloworld.proto之后,可以通过如下代码得到lm.helloworld.id的定义: 清单7.得到lm.helloworld.id的定义的代码 constprotobuf: : Descriptor*desc= importer_.pool()->FindMessageTypeByName(“lm.helloworld”); constprotobuf: : FieldDescriptor*field= desc->pool()->FindFileByName(“id”); 通过Descriptor,FieldDescriptor的各种方法和属性,应用程序可以获得各种关于Message定义的信息。 比如通过field->name()得到field的名字。 这样,您就可以使用一个动态定义的消息了。 编写新的proto编译器 随GoogleProtocolBuffer源代码一起发布的编译器protoc支持3种编程语言: C++,java和Python。 但使用GoogleProtocolBuffer的Compiler包,您可以开发出支持其他语言的新的编译器。 类CommandLineInterface封装了protoc编译器的前端,包括命令行参数的解析,proto文件的编译等功能。 您所需要做的是实现类CodeGenerator的派生类,实现诸如代码生成等后端工作: 程序的大体框架如图所示: 图4.XML编译器框图 在main()函数内,生成CommandLineInterface的对象cli,调用其RegisterGenerator()方法将新语言的后端代码生成器yourG对象注册给cli对象。 然后调用cli的Run()方法即可。 这样生成的编译器和protoc的使用方法相同,接受同样的命令行参数,cli将对用户输入的.proto进行词法语法等分析工作,最终生成一个语法树。 该树的结构如图所示。 图5.语法树 其根节点为一个FileDescriptor对象(请参考“动态编译”一节),并作为输入参数被传入yourG的Generator()方法。 在这个方法内,您可以遍历语法树,然后生成对应的您所需要的代码。 简单说来,要想实现一个新的compiler,您只需要写一个main函数,和一个实现了方法Generator()的派生类即可。 在本文的下载附件中,有一个参考例子,将.proto文件编译生成XML的compiler,可以作为参考。 Protobuf的更多细节 人们一直在强调,同XML相比,Protobuf的主要优点在于性能高。 它以高效的二进制方式存储,比XML小3到10倍,快20到100倍。 对于这些“小3到10倍”,“快20到100倍”的说法,严肃的程序员需要一个解释。 因此在本文的最后,让我们稍微深入Protobuf的内部实现吧。 有两项技术保证了采用Protobuf的程序能获得相对于XML极大的性能提高。 第一点,我们可以考察Protobuf序列化后的信息内容。 您可以看到ProtocolBuffer信息的表示非常紧凑,这意味着消息的体积减少,自然需要更少的资源。 比如网络上传输的字节数更少,需要的IO更少等,从而提高性能。 第二点我们需要理解Protobuf封解包的大致过程,从而理解为什么会比XML快很多。 GoogleProtocolBuffer的Encoding Protobuf序列化后所生成的二进制消息非常紧凑,这得益于Protobuf采用的非常巧妙的Encoding方法。 考察消息结构之前,让我首先要介绍一个叫做Varint的术语。 Varint是一种紧凑的表示数字的方法。 它用一个或多个字节来表示一个数字,值越小的数字使用越少的字节数。 这能减少用来表示数字的字节数。 比如对于int32类型的数字,一般需要4个byte来表示。 但是采用Varint,对于很小的int32类型的数字,则可以用1个byte来表示。 当然凡事都有好的也有不好的一面,采用Varint表示法,大的数字则需要5个byte来表示。 从统计的角度来说,一般不会所有的消息中的数字都是大数,因此大多数情况下,采用Varint后,可以用更少的字节数来表示数字信息。 下面就详细介绍一下Varint。 Varint中的每个byte的最高位bit有特殊的含义,如果该位为1,表示后续的byte也是该数字的一部分,如果该位为0,则结束。 其他的7个bit都用来表示数字。 因此小于128的数字都可以用一个byte表示。 大
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Google Protocol Buffer 的使用和原理 使用 原理