protobuf为什么那么快
在分布式应用或者微服务架构中,各个服务之间通常使用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 }
显然,中间有很多冗余的字符,比如{
,"
等,为了把数据变小一点,我们可以暴力一点,直接表示为:
30 | zhangsan | 175.33 | 140 |
---|
通过直接将value
拼在了一起,舍去了不必要的冗余字符,我们大幅度的压缩了空间,但是会有一些问题,就是当我们将这段数据发送给接收端,接收端怎么知道每个value
对应哪个key
呢?比如zhangsan
这个值,对应的是age
还是name
呢?
比较好的方式是事先跟接收端约定好有哪些字段,顺序是啥样子的,然后接收端按照顺序对应起来:
字段1:age | 字段2:name | 字段3: height | 字段4:weight |
---|---|---|---|
↓ | ↓ | ↓ | ↓ |
30 | zhangsan | 175.33 | 140 |
很完美,这样我们确实压缩了不少数据,棒棒的。
能不能更小一点
假设height
这个字段为null
,我们其实是不必要传递这个字段的,这个时候我们需要传递的数据就为:
30 | zhangsan | 140 |
---|
但是在接收端,解析数据并按照顺序进行字段匹配的时候就会出问题:
字段1:age | 字段2:name | 字段3: height | 字段4:weight |
---|---|---|---|
↓ | ↓ | ↓ | ↓ |
30 | zhangsan | 140 |
显然已经乱套了,为了保证能够正确的配对,我们可以使用tag
技术:
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
来提供更快的解析速度,具体的实现原理大家可以点击 这里 看。
第三:未知中...