一味宠爱|Google Protocol Buffers 序列化原理 Google的ProtocolBuffers跨语言、性能

Google 的 Protocol Buffers 跨语言、性能好，序列化后的消息体小利于传输，被广泛应用于RPC调用，数据存储。
本文一共分为 6 部分(TLV编码、压缩整形、字符串、嵌套类型、数组、Map) ，跟大家拆解 ProtoBuffer 序列化原理。
01
—
TLV 编码

T：Type，用于标识标签或者编码格式信息。
L：Length 定义数值的长度。
V：Value表示实际的数值。

这个是个比较通用的结构类型，很多序列化工具都是基于这种类型的优化。
我们来看一个简单的 proto 定义：
message Test1 {optional int32 a = 1;}最后一个数字是字段的序号(field_number) ，不能重复，每个字段有了唯一的编号，有了编号之后就可以不用存储字段名称。
正常情况下一个字段名称最少也2、3个字符，一个字符占用 2 个字节。而是用整数，再加上接下来讲的压缩整形，标识这个字段可能只需要 1 个字节就够了。
Protocol Buffers 将数据分了六种类型：

6 种类型用 3 位二进制即可保存，我们用 wire_type 代表类型，对应 TLV 编码 T 的定义如下：
T = (field_number << 3) | wire_type用低三位来存储 wire_type ，剩下存放字段序号，然后 T 再用压缩整形进行序列化。
除了第二种不定长，我们可以认为其他类型都是定长的，所以定长的类型就不需要 L ，直接 TV 就可以表示。
02
—
压缩整形
一个字节一共有 8 位，我们可以用低 7 位来存储数据，最高位表示是否需要更多字节来存储。

比如我们要存储一个 int 类型的 128， 4个字节，转换后只需要两个字节存储。

接下来我们看个示例:
当我们给 a 赋值 128 的时候，输出的序列化后的字节数组：
[8, -128, 1]

8：对应的二进制为：0000 1000 ，低3位是 0 表示使用的是压缩整形，剩下的数字是 1 ，表示序号为 1 的字段。
-128：转换成二进制：1000 0000 ，由于采用的是压缩整形，最高位是标记为，表示下一个字节跟这个字节是一起的。
1：转换成二进制：0000 0001 ，这里标志位是 0 表示到这里已经读取到所有数据了，跟前一个字节数据拼接在一起：000 0001 000 0000 ，对应的 int 类型数字是 128 。

再看个示例，当 a 的值是 -1 时，输出的序列化数组：
[8, -1, -1, -1, -1, -1, -1, -1, -1, -1, 1]这里 8 后面有 10 个字节， int32 大小是 4 个字节，算上压缩标志位最多也是 5个字节，为什么这里 10 个字节呢？其实对于 int32 类型的负数， ProtoBuffer 在序列化时候，会转换成 int64 为来处理。
【一味宠爱|Google Protocol Buffers 序列化原理】对于 -1 来说，转换成 int64 每一位都是 1 ，一共有64个 1 ， 7个一组，一共有 9 组，最后还剩一位 1，如下所示（第一组后面省略剩下相同的 8 组）1111 1111, ... , 0000 0001