Protocol Buffer

简介

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

Protocol buffers 提供了一种语言中立、平台中立、可扩展的机制，用于序列化结构化数据。您可以定义一次数据的机构化方式，然后可以使用特殊生成的源代码，使用各种语言，轻松地将结构化数据写入各种数据流和从各种数据流读取结构化数据。protocol buffers可以理解为是更小、更快、更简单的JSON或者XML，区别在于protocol buffers是二进制文件，而JSON和XML是文本格式。

Protocol buffers 是定义语言（在 .proto文件中创建）、proto 编译器生成的与数据交互的代码、特定于语言的运行时库以及写入文件（或通过网络发送）的数据的序列化格式的组合网络连接）

优点

• 性能好/效率高 时间开销：XML格式化（序列化）的开销倒还好，但是XML解析（反序列化）的开销就不太行了。因为服务器端和客户端都需要花费大量代码来解析XML，而且客户端不同浏览器之间解析XML的格式还不一致等等。导致XML解析花费的资源不是太好。而Protocol buffers的解析速度比xml、json快20~100倍 空间开销：XML格式为了有较好的可读性，引入了一些冗余的文本信息。导致XML格式文件庞大。格式复杂，所以空间开销不是太好。而Protocol buffers的消息大小只需要原json 1/10、xml 1/20到空间

• 代码生成机制 使用protobuf内置的 proto 编译器在构建时调用proto文件以生成各种编程语言的代码（在本主题后面的跨语言兼容性.proto中介绍 ）来操作相应的协议缓冲区。每个生成的类都包含每个字段的简单访问器和将整个结构序列化和解析为原始字节的方法

• 支持 向前/向后 兼容

  • 向前兼容：如果·一条消息被更改，并且未更新的客户端仍然可以立即和处理该消息，则该消息更改是向前兼容的。向前兼容性能够理解来自未来版本的消息
  • 向后兼容：如果客户端更新为新的消息类型但仍然能够理解以前的消息类型，则消息更改是向后兼容的。向后兼容能够理解来自先前版本的消息

• 支持多种编程语言 Google官方发布的Protocol Buffer目前支持C++、C#、Java、Python、Go、Ruby、Kotlin等多种语言（基本涵盖了市面上所有主流语言）

缺点

• 应用不够广

  protobuf相比XML而言，protobuf诞生时间较短。因此，在通用性方面都远不如XML。（protobuf - 2008年、XML - 1996年）由于这个原因，假如你需要提供若干对外的接口给第三方系统调用，最好暂时先不要考虑protobuf格式。

• 可读性差

  为了提高性能，protobuf采用了二进制格式进行编码。这直接导致了可读性差的问题（严格地说，是没有可读性）。虽然protobuf提供了TextFormat这个工具类，但终究无法彻底解决此问题。

• 缺乏自我描述

  一般来说，XML是自描述的，而protobuf格式则不是。给你一段二进制格式的协议内容，如果不配合相应的proto文件，那简直就像天书一般。

  其它要点

序列化和反序列化

序列化(Serialization)是将对象的状态信息转化为可以存储或传输的形式的过程。在序列化期间，对象将其当前状态写入到临时或持久化存储区。以后，可以通过从存储区中读取或反序列化对象的状态，重新创建该对象。

序列化的原本意图是希望对对象作一下“变换”，变成字节序列，这样一来方便持久化存储到磁盘，避免程序运行结束后对象就从内存里消失，另外变换成字节序列也更便于网络运输和传播

序列化：将数据结果或对象转换成二进制串的过程

反序列化：将序列化过程中生成的二进制串转回城数据结构或对象的过程 核心：对象状态的保存和重建

结构化数据

结构化数据是指采用标准化格式的数据，具有明确定义的结构，符合数据模型，遵循持久的顺序，并且易于人类和程序访问。 此数据类型通常存储在数据库中。 尽管结构化数据仅占全球数据的20％ 左右，但它是当前大数据的基础。 这是因为它非常易于访问和使用，并且使用效果要准确得多

非结构化数据是缺少可识别结构或架构的数据。这意味着它不符合预定义的数据模型，因此不适合主流关系数据库。由于没有易于识别的结构，因此很难被计算机程序读取。如今，大型企业组织生成的数据量估计将以每年 40% 到 60% 的速度快速增长。