风雨AS3 发表于 2019-2-15 17:55:40

protobuf为什么那么快

本帖最后由 TKCB 于 2019-2-16 13:10 编辑

转载:简书
网址: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 }显然,中间有很多冗余的字符,比如{,"等,为了把数据变小一点,我们可以暴力一点,直接表示为:

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

字段1:age字段2:name字段3: height字段4:weight
↓↓↓↓
30zhangsan175.33140
很完美,这样我们确实压缩了不少数据,棒棒的。

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

30zhangsan140
但是在接收端,解析数据并按照顺序进行字段匹配的时候就会出问题:

字段1:age字段2:name字段3: height字段4:weight
↓↓↓↓
30zhangsan140
显然已经乱套了,为了保证能够正确的配对,我们可以使用tag技术:

tag|30tag|zhangsantag|175.33tag|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 发表于 2019-2-16 09:53:25

看懂了,挺好的

雪原xy 发表于 2019-2-17 06:56:42

支持{:7_206:}
页: [1]
查看完整版本: protobuf为什么那么快

感谢所有支持论坛的朋友:下面展示最新的5位赞助和充值的朋友……更多赞助和充值朋友的信息,请查看:永远的感谢名单

SGlW(66139)、 anghuo(841)、 whdsyes(255)、 longxia(60904)、 囫囵吞澡(58054)

下面展示总排行榜的前3名(T1-T3)和今年排行榜的前3名的朋友(C1-C3)……更多信息,请查看:总排行榜今年排行榜

T1. fhqu1462(969)、 T2. lwlpluto(14232)、 T3. 1367926921(962)  |  C1. anghuo(147)、 C2. fdisker(27945)、 C3. 囫囵吞澡(58054)