protobuf为什么那么快

风雨AS3

转载：简书
网址：https://www.jianshu.com/p/72108f0aefca



在分布式应用或者微服务架构中，各个服务之间通常使用json或者xml结构数据进行通信，通常情况下，是没什么问题的，但是在高性能和大数据通信的系统当中，如果有办法可以压缩数据量，提高传输效率，显然会给用户带来更快更流畅的体验。
google公司就通过使用一种新的数据交换格式办到了这点，新的数据交换的格式叫做protobuf。
protobuf有多屌呢，可以看一下下面的官方测试报告：



解包耗时



数据包压缩后大小

可以看到，一条消息数据，用protobuf序列化后的大小是json的10分之一，是xml格式的20分之一，但是性能却是它们的5~100倍，我觉得用户一定会尖叫的：oh my god!。

把数据变小一点下面我们以json数据为基础出发，通过一步一步的对它进行优化，来理解protobuf的实现原理。
对于一条信息，json的表示方式为：
{ "age": 30, "name": "zhangsan",  "height": 175.33, "weight": 140 }显然，中间有很多冗余的字符，比如{，"等，为了把数据变小一点，我们可以暴力一点，直接表示为：
[td]

30

zhangsan

175.33

140

通过直接将value拼在了一起，舍去了不必要的冗余字符，我们大幅度的压缩了空间，但是会有一些问题，就是当我们将这段数据发送给接收端，接收端怎么知道每个value对应哪个key呢？比如zhangsan这个值，对应的是age还是name呢？
比较好的方式是事先跟接收端约定好有哪些字段，顺序是啥样子的，然后接收端按照顺序对应起来：
[td]

字段1：age	字段2：name	字段3： height	字段4：weight
↓	↓	↓	↓
30	zhangsan	175.33	140

很完美，这样我们确实压缩了不少数据，棒棒的。

能不能更小一点假设height这个字段为null，我们其实是不必要传递这个字段的，这个时候我们需要传递的数据就为：
[td]

30

zhangsan

140

但是在接收端，解析数据并按照顺序进行字段匹配的时候就会出问题：
[td]

字段1：age	字段2：name	字段3： height	字段4：weight
↓	↓	↓	↓
30	zhangsan	140

显然已经乱套了，为了保证能够正确的配对，我们可以使用tag技术：
[td]

tag|30

tag|zhangsan

tag|175.33

tag|140

也就是说，每个字段我们都用tag|value的方式来存储的，在tag当中记录两种信息，一个是value对应的字段的编号，另一个是value的数据类型（比如是整形还是字符串等），因为tag中有字段编号信息，所以即使没有传递height字段的value值，根据编号也能正确的配对。

Tag的开销有的同学会问，使用tag的话，会增加额外的空间，这跟json的key/value有什么区别吗？
这个问题问的好，json中的key是字符串，每个字符就会占据一个字节，所以像name这个key就会占据4个字节，但在protobuf中，tag使用二进制进行存储，一般只会占据一个字节，它的代码为：
static int makeTag(final int fieldNumber, final int wireType) {  return (fieldNumber << 3) | wireType;}fieldNumber表示后面的value所对应的字段的编号是多少，比如fieldNumber为1，就表示age，如果为2，就表示name等；wireType表示value的数据类型，以此来计算value占用字节的大小。
在protobuf当中，wireType可以支持的字段类型如下：





因为tag一般占用一个字节，开销还算是比较小的，所以protobuf整体的存储空间占用还是相对小了很多的。

能不能更小点在实际的传输过程中，会传递整数，我们知道整数在计算机当中占据4个字节，但是绝大部分的整数，比如价格，库存等，都是比较小的整数，实际用不了4个字节，像127这种数，在计算机中的二进制是：
00000000 00000000 00000000 01111111（4字节32位）
完全可以用最后1个字节来进行存储，protobuf当中定义了Varint这种数据类型，可以以不同的长度来存储整数，将数据进一步的进行了压缩。
但是这里面也有一个问题，在计算机当中的负数是用补码表示的，对于-1，它的二进制表示方式为：
11111111 11111111 11111111 11111111（4字节32位）
显然无法用1个字节来表示了，但-1确实是一个比较简单的数，这个时候就可以使用zigzag算法来对负数进行进一步的压缩，最终我们可以使用2个字节来表示-1。

要快虽然数据现在很小了，但是解析速度还是有很大的提升空间的，因为每个字段都是用tag|value来表示的，在tag中含有value的数据类型的信息，而不同的数据类型有不同的大小，比如如果value是bool型，我们就知道肯定占了一个字节，程序从tag后面直接读一个字节就可以解析出value，非常快，而json则需要进行字符串解析才可以办到。

能不能更快一点如果value是字符串类型的，具体value有多长，我们无法从tag当中了解到，但是如果不知道value的长度，我们就不得不做字符串匹配操作，要知道字符串匹配是非常耗时的。
为了能够快速解析字符串类型的数据，protobuf在存储的时候，做了特殊的处理，分成了三部分：tag|leg|value，其中的leg记录了字符串的长度，同样使用了varint来存储，一般一个字节就能搞定，然后程序从leg后截取leg个字节的数据作为value，解析速度非常快。

protobuf能帮助我们干什么？了解额protobuf的牛逼之处，对我们来说有什么好处呢？
首先，对于我们系统当中的一些大数据传输，显然用protobuf是可以获得很大的改善的，如果你这么干了，领导一定会想给你涨工资的。
第二，给我们优化数据传输提供了一种思路，通过提供更多的数据元数据（数据类型，长度等），我们可以大幅度提高解析数据，比如在nodejs当中就有一个框架叫fastify，通过给json设计了schema来提供更快的解析速度，具体的实现原理大家可以点击 这里 看。
第三：未知中...

kasher

看懂了，挺好的

雪原xy

支持