Protocol Buffers初次认识

因为项目需要所以学习了gPRC远程过程调用框架,而这个框架中就是采用Protocol Buffers进行序列化结构化数据的,这种序列化数据格式与传统的XML、JSON等格式来说,性能以及占用空间方面更小等优点,看到这里是不是有种迫不及待想深入了解下Protocol Buffers呢?

Protocol Buffers

什么是Protocol Buffers?

引用官方的说法

a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more.

Protocol Buffers是一种与语言、平台无关,可拓展序列化数据的方式,用于通讯协议,数据存储等。

Protocol Buffers是一种灵活、高效、自动化的机制,用于序列化结构化数据。可以定义数据的结构,然后使用独有的编译器轻松将结构化数据写入和读取到各种数据流中,而且支持多种语言,甚至可以在不会破坏“旧”数据格式的情况下更新数据。

Protocol Buffers是怎么运行的?

可以通过.proto后缀文件中定义Protocol Buffers消息类型来指定希望如何构建序列化信息。每个Protocol Buffers消息都是一个小的逻辑信息记录,包含了key-value键值对。如下.proto是定义人员信息的一个基本的示例:

message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phone = 4;
}

正如我们所看到的,定义的格式很简单,每种消息类型都有一个或多个唯一编号的字段,每个字段都有一个名称和一个值类型,其中值类型可以是数字(整数或浮点数),布尔值,字符串,byte,甚至可以是其他Protocol Buffers定义的消息类型,允许分层次的构建数据。在数据类型定义中可以指定字段的类型optional(可选)、required(必填)、repeated(重复,即集合) ,详细可以在《Protocol Buffer语法指南》中查看。

一旦定义了数据结构,可以将proto文件运行在Protocol Buffers编译器生成对应开发语言的数据访问类。经过编译器编译生成的相应开发平台语言的访问类,包含了简单的访问入口,以及提供将整个数据结构序列化/反序列化为原始字节的方法。

关于Protocol Buffers如何编译成相关开发平台的具体可以参考官方文档,这里提供了《Protocol Buffers基于Windows平台构建Java版本实现》

为什么不使用XML?

写到这里,可能会有小伙伴疑惑为什么不直接使用传统的XML、JSON数据格式,非得弄得这么麻烦的。
针对于传统序列结构化数据,Protocol Buffers比XML、JSON具有更多的优点。

  • 更简单
  • 比其小3到10倍
  • 运行速度上快20到100倍
  • 耦合性低
  • 可以生成更便于编译平台方式的数据访问类

例如,用上面定义好的Person举例,定义一个包含name和email的person对象,在XML中,需要:

    <person> 
        <name> John Doe </ name> 
        <email> jdoe@example.com </ email> 
    </ person>

而相应的protocol buffer消息(protocol buffer文本格式)是:

# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
  name: "John Doe"
  email: "jdoe@example.com"
}

此对象被编码为protocol buffer二进制格式(上面文本格式只是便于开发者读写编辑调试使用)时,它大概只有28字节,并且需要大约100-200纳秒来解析。而xml,即使删除空格,xml版本至少也得69字节,并且需要大约5000-10000纳秒才能解析成功。

此外,在操作对象方面来说protocol buffer也要容易得多。

但,protocol buffer相对比xml也不都是最好的处理数据的解决方案,protocol buffer不是标记语言(HTML等),对于文本文档建立结构与文本交错的建模。此外,XML是便于读写编辑的,但protocol buffer(原生格式)不是。XML可以进行自我描述,但protocol buffer只有在拥有消息定义(.proto文件)时,protocol buffer才有意义。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342

推荐阅读更多精彩内容