ProtoBuf 是一套接口描述语言(IDL)和相关工具集(主要是 protoc,基于 C++ 实现),类似 Apache 的 Thrift)。用户写好 .proto 描述文件,之后使用 protoc 可以很容易编译成众多计算机语言(C++、Java、Python、C#、Golang 等)的接口代码。(摘自:ProtoBuf 与 gRPC 你需要知道的知识)
注:本文参考Protocol Buffers 3.0 技术手册,下面给出该文章中未说明的部分
定义Message类型
1 syntax = "proto3";
2
3 message SearchRequest {
4 string query = 1;
5 int32 page_number = 2;
6 int32 result_per_page = 3;
7 }
首行指定了使用proto3语法,如果没有改行,protocol buffer编译器默认使用proto2。
field numbers
4,5,6行中指定了field number,field number的取值范围为1~(229-1)。protocol buffer的预留了19000~19999(FieldDescriptor::kFirstReservedNumber ~ FieldDescriptor::kLastReservedNumber)之间的值。
field rules
消息字段有2种规则:
default
当解析 message 时,如果被编码的 message 里没有包含特定变量,根据类型不同,他们会有不同的默认值:
注意:对于scalar(标准protobuf类型,如) message字段,一但message被解析,则没有办法来明确判断该字段设置了默认值(如没法判断一个boolean变量设置为false)或根本没有设置。因此在定义message类型的时候一定要注意,例如,如果不想在默认下有任何动作,则boolean的值在false时不要有动作。此外注意,scalar message字段在设置为默认值时,该值不会被序列化--->即反序列化scalar message字段时是无法反序列化出默认值(因为默认值不会被序列化)
未识别的字段
未识别的字段为序列数据中出现的无法解析的字段,如当老的二进制解析器解析一个包含新字段的二进制时,新字段即为无法识别的字段。
proto3可以很好地解析未识别的字段,然而proto实现时可能会也可能不会保留这些未知的字段,功能实现不应该依赖于未知字段是否保留或丢弃。
oneof
oneof类似C语言的联合体union,oneof中不能使用repeated
option
所有有效的选项都定义在google/protobuf/descriptor.proto,参见option
使用场景
多消息流
如果向一个文件或流中写入多个消息,则需要自己去跟踪一个消息的结束和下一个消息的开始。由于protocol buffers不会对自限定长度,解析器无法判定消息的结束点,简单的方式是在写入消息前先写入消息的长度。
大数据集
protocol buffer并不是设计用来处理大消息的,如果有大规格的消息,可以分割解决。