protobuf协议介绍及性能实测

protobuf是谷歌开源的一款高性能序列化框架，特点是性能优异，数据结构设计优秀并具有良好的可扩展性，并且配合官方的java、python、go、c++的sdk，可以轻松做到跨语言。本文给出protobuf协议的简单介绍以及与其他框架对比的性能测试结果。

协议简介

Protocol Buffers 是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。你可以理解为另外一种形式的xml，当然protobuf为了追求性能，可读性没有xml或者json那么好，换来的是编码后的报文容量大大缩小以及序列化速度的提高。
要使用使用protobuf，首先需要定义一个.proto格式的文件，格式类似下面这样

syntax = "proto3";
message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }
  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }
  repeated PhoneNumber phone = 4;
}

目前有v2和v3两种版本，api会略有不同。
修饰符：

required : 　不可以增加或删除的字段，必须初始化；
optional : 　可选字段，可删除，可以不初始化；
repeated : 　可重复字段，对应到java文件里，生成的是List。

更多介绍可参考官网。
执行

protoc ./message.proto --java_out=./

可在当前目录下生成对应对应语言的对象描述代码，这边对应的是java的class文件，再把文件拷贝到项目工程目录内，就可以使用了。（需要下载对应语言的protoc二进制程序）
这边是一个简单的proto报文生成过程

timg.jpg

大家如果之前用过web service的话，应该会有似曾相识的感觉。这个proto文件，我理解为类似于SOAP的wsdl描述文件，即是一份用来描述数据结构的标准文档说明，各语言的sdk可根据该语言的proto文件生成标准的类文件（是不是想起来了wsdl2java），从而达到跨语言的远程调用（RPC调用）。然而实际使用中，基于这种模式使用还是比较麻烦，如果对象多了要写一堆proto定义文件，另外生成出来的java对象可读性也比较差，和平时用的pojo有很大不同。本文介绍一种更加方便的使用protobuf的方法，就是protostuff。利用这个框架，可以跳过编写proto文件的步骤，直接生成protobuf格式的报文，接收端也可以直接使用该框架将二进制反序列化为Object对象，用到的就是我们平时使用的普通的java对象。利用Protostuff-Runtime模块可以不需要静态编译protoc，只要在runtime的时候传入schema就可以了。下面就来实操一下
首先引入maven依赖


       io.protostuff
       protostuff-core
       1.6.0


       io.protostuff
       protostuff-runtime
       1.6.0

编写java对象，这边为了测试写了一个比较复杂的属性带一个循环列表的对象

package com.bocsh.proto;

import java.util.List;

public class User {
    
    private String id;

    private String name;

    private Integer age;

    private String desc;
    
    private List roleList;

   //setter getter  略..
    @Override
    public String toString() {
        return "name=" + name + ",id=" + id + ",age=" + age + 
                ",role1=" + roleList.get(0).getId() + 
                ",role2=" + roleList.get(1).getId();
    }

}

package com.bocsh.proto;

public class Role {
    
    private String id;

    private String name;

    private String desc;

    //setter getter  略..

}

编写测试类进行测试

public class ProtoBufUtilTest {
     
    public static void main(String[] args) throws Exception {
 
        User user = new User();
        user.setAge(300);
        user.setDesc("备注");
        user.setName("张三");
        user.setId("HO123");
        
        List list = new ArrayList();
        for(int i=1;i<=2;i++) {
            Role role = new Role();
            role.setId("R" + Integer.toString(i));
            role.setName("经办");
            list.add(role);
        }
        
        user.setRoleList(list);
        
        //protobuf序列化
        long proto1 = (new Date()).getTime();
        LinkedBuffer buffer = LinkedBuffer.allocate(LinkedBuffer.DEFAULT_BUFFER_SIZE);
        Schema schema = RuntimeSchema.getSchema(User.class);
        ProtobufIOUtil.toByteArray(user, schema, buffer);
        byte[] serializerResult = ProtoBufUtil.serializer(user);
 
        System.out.println("protobuf序列化二进制:" + bytes2hex(serializerResult));
        System.out.println("protobuf序列化ascii:" + new String(serializerResult));
        System.out.println("protobuf序列化字节长度:" + serializerResult.length);
        User protouser = new User();
        ProtobufIOUtil.mergeFrom(serializerResult, protouser, schema);
 
        long proto2 = (new Date()).getTime();
        System.out.println("protobuf反序列化结果:" + protouser);
        System.out.println("protobuf序列化耗时:" + (proto2 - proto1));
        
    }
 
}

运行后结果如下

protobuf序列化二进制:0A 05 48 4F 31 32 33 12 06 E5 BC A0 E4 B8 89 18 AC 02 22 06 E5 A4 87 E6 B3 A8 2A 0C 0A 02 52 31 12 06 E7 BB 8F E5 8A 9E 2A 0C 0A 02 52 32 12 06 E7 BB 8F E5 8A 9E 
protobuf序列化ascii:
�HO123��张三���"�备注*
�R1��经办*
�R2��经办
protobuf序列化字节长度:54
protobuf反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
protobuf序列化耗时:185

protobuf报文在实际传输中是以二进制方式传输的，这里为了方便分析，我把它专成了ascii字符。可以看到，protobuf的压缩效率非常高，除了基本的字段内容之外，其他的标签之类的全部都压缩了，以二进制方式存储，所以它的报文格式会比xml小非常多，当然代价就是可读性没有那么友好，这也是为什么谷歌要定义proto文件的原因。在没有这个文件的情况下，你几乎不可能看懂这个报文所表示的数据结构。

性能测试

说了那么多，现在来看看实际protobuf能为我们带来多少传输报文的性能提升。这里我选取了目前日常使用最普遍的XML以及json格式，这两个是文本形式的序列化框架，以及hessian2，这个是老牌的二进制序列化框架，也是dubbo里默认的序列化方案。几种格式都可以做到跨语言，现在我们来看看他们的性能差距到底有多少。
一些基本情况说明：
测试环境：macbook pro 笔记本(2012 late,core i5 2.5GHz,8G内存）
java版本：jdk1.8
protobuf序列化框架：protostuff
xml序列化框架：jdk原生jaxb
json序列化框架：fastjson
hessian序列化框架：hessian
测试方法：将List循环多次，模拟不同的报文size大小，以此测试序列化框架的性能。

size=10

protobuf序列化字节长度:167
protobuf反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
protobuf序列化耗时:196

xml序列化字节长度:645
xml反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
xml序列化耗时:149

json序列化字节长度:350
json反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
json序列化耗时:223

hessian2序列化字节长度:690
hessian2反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
hessian2序列化耗时:63

可以看出在数据量很小的情况，几个框架的性能差别不大，hessian2最好，xml甚至比protobuf还要高一些。但是有一个地方需要注意，就是序列化后的字节长度，json是xml的大概1/2多一点，而protobuf只有xml的1/4，而hessian甚至比xml还要长。这在存储敏感或者带宽敏感的场景下是至关重要的。之后的所有测试存储所占空间的比例基本都是一样。

size=1000

protobuf序列化字节长度:15919
protobuf反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
protobuf序列化耗时:211

xml序列化字节长度:53027
xml反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
xml序列化耗时:256

json序列化字节长度:29962
json反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
json序列化耗时:249

hessian2序列化字节长度:60992
hessian2反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
hessian2序列化耗时:114

当数据量来到1000这个量级，仍然是hessian一马当先，可以看到protobuf已经反超xml了，这时候json的性能也已经超过xml，xml的劣势开始渐渐显现。

size=100000

protobuf序列化字节长度:1788921
protobuf反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
protobuf序列化耗时:333

xml序列化字节长度:5489029
xml反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
xml序列化耗时:1059

json序列化字节长度:3188964
json反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
json序列化耗时:726

hessian2序列化字节长度:6288994
hessian2反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
hessian2序列化耗时:785

来到10万这个量级，protobuf反超！而且优势非常明显，几乎是xml性能的3倍，hessian的2倍，序列化后的字节大小为1.7M左右，xml的1/4

size=1000000

protobuf序列化字节长度:18888922
protobuf反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
protobuf序列化耗时:2405

xml序列化字节长度:55889030
xml反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
xml序列化耗时:4087

json序列化字节长度:32888965
json反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
json序列化耗时:3063

hessian2序列化字节长度:63888995
hessian2反序列化结果:name=张三,id=HO123,age=300,role1=R1,role2=R2
hessian2序列化耗时:4747

数据量为100万条，此时protobuf的报文数据大小为18M，xml已经达到了55M，json也有33M，hessian更是到了64M，protobuf的速度仍然是xml的差不多两倍。这里比较诡异的是json在好几次测试中耗时只有1000多ms，但多测几次又会变回3000多ms，从生成的字节码来看，3000ms是比较合理的结果，不知道是做了什么样子的优化。

结论

在报文数据量很小的情况，几种格式差别不是很大，建议都可以选择。如果对于报文解析性能要求很高，报文体积小的情况下可以选择hessian，体积大选protobuf。如果需要文本格式，选择json。如果对于存储或者带宽敏感，建议选择protobuf，体积比其他几种格式小太多，传输或者存储都很方便。

补充说明

看了protobuf的官方文档，感觉protobuf的性能还有提高的空间，就用原生的protobuf测试了一下，静态编译了user.proto文件，测试结果如下

数据量大小:10
原生protobuf序列化字节长度:167
原生protobuf序列化耗时:54

数据量大小:1000
原生protobuf序列化字节长度:15919
原生protobuf序列化耗时:86

数据量大小:100000
原生protobuf序列化字节长度:1788921
原生protobuf序列化耗时:289

数据量大小:1000000
原生protobuf序列化字节长度:18888922
原生protobuf序列化耗时:2371

可以看出性能有了很大的提高，在各阶段的测试中都是最快的。对比编码后的字节数，和protostuff是完全一致的，说明两种框架最终出来的结果是一样的，但是原生的protobuf要快了很多，看来果然鱼和熊掌不可兼得，运行时的编译对于性能相比静态编译还是有相当的损耗的。在小于1000的数据量级，两者的性能差距差不多有3倍。对于极致追求性能的场景，还是建议使用原生的protobuf。当然本次测试结果还没有达到官方宣称的比xml要快20～100倍这个数量级，这个估计需要C++或者go的环境下才能实现，留给其他同学进行测试了。

测试用到的github代码地址

protobuf协议介绍及性能实测

协议简介

性能测试

结论

补充说明

你可能感兴趣的:(protobuf协议介绍及性能实测)