Google Protocol Buffers 概述

标签: google protocol buffers | 发表时间:2013-04-08 09:55 | 作者:石头儿
出处:http://www.cnblogs.com/

1. 概述

Protocol Buffers 是一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,或者说序列化。它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前提供了 C++、Java、Python 三种语言的 API。

本文概述介绍Protocol Buffers,以及开始如何开始Protocol Buffers之旅,本系列主要以Java为主(虽然超想看Python的,无奈学的还不够...)。

以下Protocol Buffers简称PB。

2. Protocol Buffers是什么

Protocol Buffers提供了一种灵活,高效,自动序列化结构数据的机制,可以联想XML,但是比XML更小,更快,更简单。仅需要自定义一次你所需的数据格式, 然后用户就可以使用Protocol Buffers自动生成的特定的源码,方便的读写用户自定义的格式化的数据。不限语言,不限平台。还可以在不破坏原数据格式的基础上,依据老的数据格式, 更新现有的数据格式。

3. Protocol Buffers如何工作的

在PB中,有一种.proto类型的文件,用户 在.proto文件中定义PB “Message”来指定所需要序列化的数据的格式。每一个PB Message都是一个小的信息逻辑单元,包含了一些列的name-value对。下面举例说明一个简单地.proto文件,他定义了一条包含一个 Person信息的Message:

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;
}

如上代码所示,PB message 格式非常简单。每种类型的message包含一个或者多个唯一编码字段,每个字段由名称和值类型组成,值类型可以使数字(整形或者浮点型),布尔值,字符 串,原始字节,甚至是其他的PB message。PB允许message中包含message,已达到分层嵌套。可以定义可选字段,必填字段以及重复字段。想要了解更多如何 写.proto 文件,可以访问: Protocol Buffer Language Guide

定 义好PB message后,选择合适语言的PB编译器,编译.proto文件,就可以生成存取数据的相关类。这些类包括简单的设置及读取字段的方法,也包括对整个 数据结构的message与二进制之间的转换。举个例子,如果你使用的语言是java,运行编译器编译上例.proto文件后,生成的类中包含一个 Person类。使用该类,就可以计算,序列化以及检索PB message。如下代码:

public static void main(String[] args) throws IOException {
Person john = Person
.newBuilder()
.setId(1)
.setName("john")
.setEmail("[email protected]")
.addPhone(
PhoneNumber
.newBuilder()
.setNumber("1861xxxxxxx")
.setType(PhoneType.WORK)
.build())
.build();
FileOutputStream output = new FileOutputStream("abc.txt");
john.writeTo(output);
output.close();
}

接下来,你可以用如下代码读取:

public static void main(String[] args) throws IOException {
FileInputStream input = new FileInputStream("abc.txt");
Person person = Person.parseFrom(input);
System.out.println(person.getId());
System.out.println(person.getName());
System.out.println(person.getEmail());
System.out.println(person.getPhoneCount());
System.out.println(person.getPhone(0).getNumber());
System.out.println(person.getPhone(0).getType());
}

PB是易于扩展的,可以向后兼容的,我们可以在PB message中添加新的字段,这样,在parse的时候,老版本的数据就会简单的忽略新增加的字段。因此,如果现有通信协议使用了PB作为其数据格式,我们可以直接扩展该通信协议,而不必担心这将会破坏现有的代码。

对于使用.proto文件生成PB 客户端代码,可以参看这方面的完整教程: API Reference section。想要学习了解PB message是如何编码的,可以参见: Protocol Buffer Encoding

 4. 为什么不直接使用XML呢?

如果要序列化结构化数据,比起XML,PB实在是有许多的优点可以道道~

  1. 更简单
  2. 比XML小3~10倍
  3. 比XML快20~100倍
  4. 语义定义明确
  5. 自动生成数据存取类,更容易使用

假如我们要模拟一个Person,该对象包含name和email属性,如果用XML,我们定义如下:

<person>
<name>John Doe</name>
<email>[email protected]</email>
</person>

对应的,PB如下:

person {
name: "John Doe"
email: "[email protected]"
}

请注意:这里仅是PB格式的一种直观表示,真实的PB并非这样存储,实际上,在链路中,PB数据时二进制格式的。

当这段数据编码为PB二进制格式时,其实际大小大概是28bytes,编码时间为100~200纳秒。如果用XML的话,即使去除空格,大小也至少为69bytes,编码时间大概需要5000~10,000纳秒。

同样,解析这段代码,PB比XML要方便许多。用PB的话:

person.getName();
person.getEmail();

而用XML的话:

personNode.getElementsByTagName("name")
personNode.getElementsByTagName("email")

相比起来,PB更直接,而且不需要遍历节点等XML操作。

但是,金无足赤,人无完人,PB也一样。对于有很多标签的,基于文本的数据(例如HTML),XML就完胜PB。XML是子描述的,可以随机且交错读取读取文本节点。XML是自描述的,而PB不是,PB必须要有格式定义文件(.proto 文件)

 5. 一点历史

PB由Google开发,最初是用于处理索引服务器的请求/响应协议。在有PB之前,Google使用手动编组和解组的方式来处理请求/相应协议。这种方式需要支持许多版本的协议,这就导致一些代码非常的丑陋,例如:

if (version == 3) {
...
} else if (version > 4) {
if (version == 5) {
...
}
...
}

另外,这种显示格式的协议同样将新发布的协议版本也搞得非常复杂,因为开发者必须在启用新的协议之前,确认所有的服务器,包括请求的发起者以及实际处理请求者,他们都能够理解新的协议。

PB即被设计来解决这些问题:

  1. 要可以非常容易的引入新字段,不需要检查数据的中间服务器 能够简单地解析数据,并且无须知道数据所有的字段就可以传输数据。
  2. 格式能够更加的自描述一些,并且可以被多用语言处理(C ++, Java,Python等)

至此,虽然解决了诸多问题,但用户依然需要手写他们的解析及编码代码。

随着系统的发展,PB逐渐形成了许多新的特性及用法:

  1.  自动生成序列化及反序列化代码,避免手动解析
  2. 除了被用在短生命周期的RPC请求,也开始将PB作为一种方便的自描述格式去存储持久化数据。
  3. Server RPC interfaces 开始被声明为协议文件的一部分,使用PB compiler 生成stub类,用户可以使用自己实现的服务器接口来覆盖他们。

Google Protocol Buffer( 简称 Protobuf) 是 Google 公司内部的混合语言数据标准,目前已经正在使用的有超过 48,162 种报文格式定义和超过 12,183 个 .proto 文件。他们用于 RPC 系统和持续数据存储系统。

译自:https://developers.google.com/protocol-buffers/docs/overview

初次尝试翻译,诸多不够信达雅之处,还望能够不吝指出不到之处,谢谢~

本文链接

相关 [google protocol buffers] 推荐:

Google Protocol Buffers 概述

- - 博客园_首页
Protocol Buffers 是一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,或者说序列化. 它很适合做数据存储或 RPC 数据交换格式. 可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式. 目前提供了 C++、Java、Python 三种语言的 API.

三段序列化代码的测试:比较protocol buffers的CodedOutputStream和java自带的DataOutputStream

- ndv - snnn的blog
最近一段时间在写一个小东西,一个很简单k-v数据库. 我并没有像MyISAM那样把每个表放在一个单独的文件中,而是用一个总的大文件来放所有的表. (类似于InnoDB默认的方式). 我需要在这个硕大无比的文件的开头放一个map,key是表名,value是这个表的第一个页在此文件中的偏移地址. 即这样一个结构:Map < String, Long > headers.

Google Protocol Buffer 简单介绍 - zhanjindong

- - 博客园_首页
以下内容主要整理自 官方文档. 为什么使用 Protocol Buffers. Protocol Buffers 语法. 为什么使用 Protocol Buffers. 通常序列化和解析结构化数据的几种方式. 使用Java默认的序列化机制. 这种方式缺点很明显:性能差、跨语言性差. 将数据编码成自己定义的字符串格式.

latch:cache buffers chains的优化思路

- - CSDN博客数据库推荐文章
        数据块在buffer cache存放是以linked list方式存放的. 当一个session想要访问/修改buffer cache的block,首先需要通过hash算法检查该block是否存在于buffer cache中,检查相同的SQL语句是否存在于library cache中也是通过hash算法实现的.

谷奥: Google = Google+

- 吞佛 - 谷奥聚合——谷奥主站+谷安 aggregator
在上周举办的Google Zeitgeist 2011大会上,John Battelle问Larry Page:在Google大部分的历史里,人们会想到搜索,那么Google品牌=搜索. 但在随后Google的发展史里,Google品牌会等于什么. Larry Page并未直面回答这个问题,至少没有从市场角度来回答.

Google宣布Google CDN

- way - Solidot
Google宣布了最新的帮助加快互联网速度的工具Page Speed Service,加快静态网页的载入速度,不支持动态网页. 在开发者注册该服务之后,可将网站的DNS入口记录指向Google,然后Page Speed Service从服务器上抓取内容,采用最佳的Web性能方案重写网页,通过Google在全球部署的服务器将内容展示给终端用户,加快网页载入速度.

Google将关闭Google Labs

- yifan - Solidot
Google宣布将关闭Google实验室,搜索巨人表示此举将帮助他们将精力集中在优先的产品项目上. Google称,关闭Google实验室意味着大部分试验项目将会被放弃,但不是每一个项目都会被抛弃. Google会将部分试验项目整合到其它产品中. Android应用程序如Google Goggles和Google Listen,则将会继续留在Android Market中.

當Google Docs遇上Google Finances

- 沒有暱稱 - 海芋小站
Google Finances是由Google所推出的一個財經服務,裡面記錄了全球的財經資訊,而如果我們要在Google文件中插入這些財經資訊,如某支股票的收盤價,開盤價等資訊,那要怎麼辦到呢. Google其實提供了非常簡單的函式,怎麼用就往下看啦. 其實在Google文件的試算表中,以插入股票為例,只要輸入「=GoogleFinance("股票代碼.tw"; "參數")」就可以了,以鴻海為例,代碼就是「2317」,記得一定要加變成「2317.tw」才可以.

Google Reader将和Google+整合

- Richard - 月光博客
  Google Reader官方博客宣布,即将对Google Reader进行重大改版,并和Google+进行整合,新版本将重新设计,包括friending、following等功能将会被删除. 之前Google Reader的社交功能是和Buzz整合,随着Buzz的关闭,Google Reader的改版有可能会和以前的Buzz一样,将关注和被关注整合到Google+中,然后用户在Google Reader的分享自动同步到Google+.

谈谈 Google+

- Michael - 云风的 BLOG
Shared by 令狐虫. Google+ 这这些点上给出了技术上的方案,却没有给使用者明确的使用引导. 对于 Geek 来说,这些功能是有趣的. 但是,它极端依赖人的正确使用,你还无法管得了别人的错误使用,在良好的信息过滤这一点上,作为信息接收方来说,几乎没有好的方法. Google 正式发布 Google+ 的时候,我在山上.