移动场景下通信协议Json,FlatBuffers、ProtocolBuffers、MessagePack选优

最新推荐文章于 2024-08-29 15:32:15 发布
最新推荐文章于 2024-08-29 15:32:15 发布
阅读量925 收藏 1
点赞数
分类专栏： go学习 
 
 

  
  
大家都知道JSON是纯文本协议，优点是可读性高，使用简单方便；而正是它的优点造成了它解析费时、解析内存耗费高、及数据量大的问题。在移动场景对性能要求极高的情况下，选择JSON作为通信协议无疑不是最佳。为了解决上述问题，特对MessagePack、FlatBuffer、ProtocolBuffers这几种当下流行的通信协议进行了学习研究，与JSON相对比，综合不同场景分析协议的优劣之处。
首先简单介绍一下几种协议的基本原理及其用法。
FlatBuffers，可参见FlatBuffers在android的使用简介、android FlatBuffers剖析
MessagePack，参见MessagePack简介及使用
ProtoBuf，参见ProtocolBuffers的编码、Android Studio使用ProtocolBuffers
网上有很多对这几种数据协议的对比和评论，但大都范范的给出FB更好或者是PB更优的结论，我想说这是很不严谨的，不同的数据格式、真实数据的内容、数据的复杂度等都影响了几种协议的对比效果。而实际使用场景中也必须从序列化反序列化速度、内存耗费、使用成本等方面综合考虑。
下面就从几大方面选取不同数据样本进行分析对比，希望能给大家一个参考。


  
  
第一种对比方式，改变样本量大小看对比结果


  
  
样本1数据样式


  
  
{
  "error_no":0,
  "message":"",
  "result":{
    "data":[
      {
        "datatype":1,
        "itemdata":
            {//共有字段45个
              "sname":"\u5fae\u533b",
              "packageid":"330611",
              …
              "tabs":[
                        {
                          "type":1,
                          "f":"abc"
                        },
                        …
              ]
            }
      },
      …
    ],
    "hasNextPage":true,
    "dirtag":"soft"
  }
}

  
  
测试方式

  
  
通过填充data的数据个数来扩大样本容量，选取JSON格式下的6K（data数据=1）、30K(data数据=7)、60K(data数据=15)、600K(data数据=154)、6000K(data数据=1540)、12000K(data数据=3080)为样本。
从客户端角度，对比以下四方面：序列化后原始数据大小、反序列化耗时、反序列化耗内存大小。结果对比主要选择6K、30K、60K、600K、6000K的测试结果进行。

  
  
测试结论

  
  
1. 序列化后数据大小对比

  
  
相同的数据内容用不同格式编码，进行存储后的文件大小数据如下表：

  
  

   
   
   
   

   
   

  
  

  
  

   
   
   
   

   
   

    
    序列化数据压缩对比图
   
   

  
  

  
  

按照节省的空间从大到小排序：msgpack> pb>fb>json。由于该数据样本中基本数据类型(int,float等)较少，因此pb对基本数据类型进一步zigzag编码的优势没有充分体现，但与msgpack数据相差不大。
排名：msgpack> pb>fb

  
  
2. 反序列化耗内存大小对比

  
  
相同的数据内容按不同格式编码后，读取到内存中，进行反序列化操作，查看占用的内存情况

  
  

   
   
   
   

   
   

  
  

  
  

   
   
   
   

   
   

    
    反序列化耗费内存大小对比.png
   
   

  
  

  
  

反序列化耗费内存从大到小排序msgpack>json>pb>fb，msgpack耗费内存约为json的1.6倍，fb、pb耗费内存差别不大。
    排名：fb>pb >msgpack

  
  
3. 反序列化耗时

  
  
将序列化后的数据读取到内存后，开始计算反序列化成完整java对象的时间

  
  

   
   
   
   

   
   

  
  

  
  

在解析耗时方面这几种数据格式都优于json，排名：pb>msgpack>fb。

  
  
4. 该对比方式下的结论：

  
  
在反序列化耗内存大小方面，msgpack远远超出json（1.6倍），由于内存是移动客户端场景下的重要指标，因此基本可以排除msgpack。
只看pb和fb的排名:
序列化后大小：pb>fb
反序列化耗内存: fb>pb
反序列化耗时：pb>fb
综合来看pb更优

  
  
第二种对比方式：考虑层级对结论的影响

  
  
排除了msgpack后，我们对pb和fb进行进一步分析，考虑样本对对比结果的影响，选取两种样本：

  
  
样本选取

  
  
样本2将层级内数据减少到最小

  
  
{
   "error_no":0,
   "message":"",
   "result":{
          "data":[
             {
                "datatype":1,
                "itemdata":
                            {
                              "sname":"微信",
                              "tabs":[
                                       {
                                        "type":1
                                        }
                                      ]
                             }
             },
             ……
          ],
       }
}

  
  
样本3层级为0，数据个数多

  
  
{//共有字段45个
"sname":"微信",
"packageid":"330611",
 … 
}

  
  
测试方式

  
  
选取样本2、样本3序列化后的数据分别进行1000次反序列化，对比总耗时和总耗费内存

  
  
测试结论

  
  
1. 序列化后数据大小对比

  
  
样本类型FB(kb)PB(kb)
样本20.210.06
样本34.083.65

  
  
pb比fb序列化后更省空间,这个结论与上面结论相同，可见PB在不同样本下序列化后的内存大小更佳。

  
  
2. 反序列化耗内存大小对比

  
  
样本类型FB(kb)PB(kb)
样本21086943
样本3765011160

  
  
数据量较大时FB比PB解析更省内存，层级较深时PB更省内存。

  
  
3. 反序列化耗时对比

  
  
样本类型FB(ms)PB(ms)
样本2415546
样本31614991

  
  
可见，当数据样式层级及结构复杂度较高，而层级内数据量不大时，反序列化耗时FB更有优势，但两者差别不大，当层级内数据量较大时，PB更省时间。

  
  
进一步结论，干货时间！！！

  
  
  1. 在序列化后的存储空间占用方面，PB绝对优于FB，假设样本中数字较多时，PB的优势将更明显，因为zigzag的编码让数字变得更省空间。
  2. 在解析耗时方面，PB更优。虽然当数据层级较深而层级内数据量较小时，FB更有优势，而一旦层级内数据量变大，则PB会更省时间。为什么PB在这种场景下更快呢？分析这可能与FB的寻址方式有关，每个变量的读取都需要先去vtable查询偏移量，再根据偏移量移动指针读取数据，而偏移量都是基于vtable基准点计算得出的，每次读取都需要从基准点处重新寻址，而且读取过程没有顺序可言，当层级内数据较多时全部读取完毕需要更长时间。而PB不需要这么复杂的过程，直接顺序读取完毕，按k-v的对应关系赋值给相应变量即可。因此，FB更适合存储大块二进制数据，比如图片、游戏数据等；PB更适合短而复杂的通信协议。
  3. 在解析耗内存方面，FB比PB更优。这也是由存储方式以及协议的复杂度决定的，FB在访问数据时不需要创建临时内存，每个数据的存储位置可以认为是指定好的，直接读取内存就可实现反序列化，不需要复杂的解析逻辑，因此省去了很多中间对象的创建、内存申请；而PB是K-V存储方式，每个数据存放的先后顺序及位置是不能预知的，因此需要遍历过程去完成数据的解析，然后包装对应到对象，比FB多了解析过程。

  
  
实际传输场景下的选优

  
  
笔者项目目前的通信协议基本为样式1所示数据格式，按分析结论选择PB为最佳，但在实际通信场景中是否如此呢，为此做了进一步验证。

  
  
测试方式

  
  
一次传输过程中数据传输前压缩（Gzip）和不压缩两种情况下，对比客户端总内存消耗和传输流量降低、传输耗时几方面。
基于样本1数据，取PB、FB与JSON进行对比。样本数据60K（Json格式下）。

  
  
1. 内存开销及传输流量对比

  
  
协议及压缩方式原始数据序列化压缩后大小传输大小解压用内存反序列化内存客户端总内存耗费内存开销降低传输流量降低
JSON+gzip606014.2214.22200.41473687.63无无
PB+gzip603313.4113.41167.65133314.0654%6%
PB6033无33013316676%-132%
FB+gzip6038.1215.1215.12184.02130329.1452%-6%
FB6038.12无38.120130168.1276%-168%

  
  
结论：

  
  
  1. 不采用GZIP压缩直接进行二进制传输对内存开销降低影响明显，但反面影响是传输流量会增长1.3到1.7倍不等。考虑非WIFI用户的流量成本，建议仍然使用GZIP压缩的方式。
  2. FB+GZIP的传输流量JSON+GZIP方式还要多，且总内存耗费要高于PB+GZIP
    因此选择PB+GZIP。

  
  
2. 整体耗时

  
  
一次传输完成耗时=通信耗时+解压缩耗时+反序列化耗时，由于压缩后的数据大小相差并不明显，因此同是GZIP压缩后再传输对通信时间的影响可忽略不计。因此数据从传输开始到解析完成的耗时只受解压缩耗时和反序列化耗时两方面影响。
对比几种数据解压缩耗时结果如下表

  
  
Data个数JSONFBPB
152.42.71.9
15419.322.216
1540173.9180.8157.8
3080327.4304.6237.9

  
  
结论：
可见不同数据格式压缩后的解压耗时时间差别不大，优劣排名PB>FB。
    而反序列化耗时方面PB>FB，因此采用PB+GZIP优于FB+GZIP

  
  
结论

  
  
验证结果表明，选择PB更适合，传输前仍然需要GZIP压缩。

  
  
集成成本

  
  
分析了协议本身的优劣，我们再来看一下不同协议的使用成本。

  
  
1. android端几种方式的jar包大小对比

  
  
协议jar大小(kb)
msgpack114
pb-lite241
fb11

  
  
2. 集成难度对比

  
  
  • Msgpack
    优势：无需编译java文件
    缺点：解析需要自己写，没有封装类，序列化和反序列化需要严格对齐格式及顺序，容易出错；另外空字段需要占位；数据结构有嵌套时使用Extension封装较麻烦。还有其他的问题还未验证到。
  • Fb&pb
    优势：解析工作已经在编译生成的类中完成，只需要序列化工作；序列化时各字段顺序不必按指定顺序，也可不填写某些字段；两端只需维护一个schema文件即可。
    缺点：
    需编译，先编写schema再编译成各平台语言。有一定的维护成本。
    数据和对象样式有强关联，用起来不是很灵活，比较适合数据协议固定且数据量大的通信场景。
    编译后的java类注释丢失，代码可读性较差
    测试复杂度提高
    fb的使用比pb更麻烦一点，多了一步数据索引的创建。
  • Json
    优点：数据透明，使用方便，测试成本低
    缺点：不安全，解析耗时，内存耗费高

  
  
几句话总结

  
  
选择哪种通信协议要根据自己的场景结合不同协议的特性综合考虑，没有一种绝对最优的协议，只有最合适的。
除了协议本身的优劣之外，还需要综合考虑集成成本、对包大小影响等因素。
最后，最重要的，关键要看想要解决的问题是什么。如果从使用成本，方便性上选择，那json是最佳，那就要牺牲内存和时间。如果从解析速度上考虑，那就要降低对包大小等方面的要求。

 
 


作者：爱唱歌的王小猫
链接：http://www.jianshu.com/p/987c4d16c48b
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
fjgui
关注
专栏目录
Protobuf 介绍与实战6：Protobuf、Json作为数据存储场景介绍(将Protobuf对象存储成文件后，为什么有些内容还是能看懂呢？
码二哥的技术池
12-31 1299
  1  go grpc-go 相关技术专栏 总入口   2  Protobuf介绍与实战 图文专栏 文章目录 在使用protobuf作为数据存储场景前，我们可以先尝试一下，使用JSON的情况。 1、使用json作为数据存储的场景 2、使用protobuf作为数据存储的场景 3、为什么将protobuf类型的对象存储到文件后，有些内容，还是可读的呢？ 其他解释： https://developers.google.cn/protocol-buffers/docs/encoding#structur
【协议】MessagePack, Protocol Buffers和Thrift序列化框架原理和比较说明
小鱼菜鸟的博客
10-30 206
非常好的说明文章，转自：http://jimmee.iteye.com/blog/2042420 第1部分messagepack说明 1.1messagepack的消息编码说明 为什么messagepack比json序列化使用的字节流更少，可通过图1-1、图1-2有个直观的感觉。 图1-1mess...
对比MessagePack和Protocal Buffer
余璜的技术博客
11-13 6590
原文：http://www.igvita.com/2011/08/01/protocol-buffers-avro-thrift-messagepack/ "The Best" Serialization Format Reflecting on the use of Protocol Buffers at Google and all of the above competitors i
Protobuf、MessagePack、MemoryPack 序列化协议该如何选择
最新发布
weixin_41316824的博客
08-29 337
总的相关数据如下表所示，原始数据可以在文末的Github项目地址获取：从图表来看，如果要兼顾序列化后大小和性能的话我们应该要选择，它序列化以后的结果最小，而且兼顾了性能：不过由于MemoryPack目前需要.NET7版本，所以现阶段最稳妥的选择还是使用Lz4压缩算法，它有着不俗的性能表现和突出的序列化大小。回到文首的技术选型问题，笔者那个项目最终选用的是这个序列化协议和框架，因为当时考虑到需要和其它语言交互，然后也需要有较小空间占用，目前看已经占用了111GB的Redis空间占用。
移动端通信协议选择：json、flatbuf、protobuf、MessagePack
q610098308的专栏
03-03 3548
JSON: 1、JSON是纯文本。 2、JSON具有良好的自我描述性，便于阅读。 如果对性能要求不高，传输数据少，优先选择这个，现在大部分使用的是这个； protobuf: 语言无关、平台无关。即 ProtoBuf 支持 Java、C++、Python 等多种语言，支持多个平台 高效。即比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更为简单 扩展性、...
【Android】FlatBuffer与Json
weixin_30519071的博客
07-11 203
你可能会问，既然我们已经有很标准的JSON以及转换库比如GSON和Jackson，为什么还要使用新的工具呢？ 不妨先试一下FlatBuffers，然后你就会发现它比JSON快得多。 FlatBuffers是什么？ FlatBuffers是一个高效的跨平台序列化类库，可以在C++、C#、C、Go、Java、JavaScript、PHP和Python中使用。是Google开发的，是为了应用在游戏...
新型序列化类库MessagePack，比JSON更快、更小的格式
weixin_34080951的博客
11-12 207
MessagePack is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it’s faster and smaller. Small integers are encoded into a single byte, and ...
数据通信-序列化协议 protocol json
09-17
数据通信-序列化协议 protocol json 在数据通信中，序列化协议扮演着非常重要的角色。序列化协议是指将数据结构或对象转换成二进制串的过程，而反序列化则是将序列化后的二进制串反向还原成数据结构或者对象的过程...
swift-请求ProtocolBuffers和JSON的Swift示例
08-15
在Swift编程中，Protocol Buffers（简称Protobuf）和JSON都是常见的数据序列化格式，用于在应用程序之间交换结构化数据。Protocol Buffers提供了一种高效、跨语言的序列化机制，而JSON则是一种轻量级的文本数据交换...
FlatBuffers vs Protocol Buffers
热门推荐
架构师专栏
01-23 2万+
介绍FlatBuffer，并和ProtocolBuffer做了简单的性能对比
protocol buffers 官网中文教程
11-06
Protocol Buffers在效率和灵活性上优于XML或JSON等文本格式，更适用于网络通信和存储。 Protocol Buffers的使用流程主要包括以下步骤： 1. **定义数据结构**：使用.proto文件定义数据结构，这是一种简单的类似编程...
替代Protocol buffers 的FlatBuffers：高效利用内存的序列化函数库（Unity中测试）
游戏路上的小学生
07-04 6402
孙广东   2015.7.4 http://www.open-open.com/lib/view/open1441004786315.html             虽然FB的反序列化超级快，但是数据大小还是蛮大的（可能的原因是不需要解析，直接访问binary buffer，所以不能对数据进行压缩），带来的传输或存储开销，可能会抵过一部分反序列化的时间。感觉上，FB的使用场景上还是很受限，在移动
序列化测试：此仓库是探索三个序列化库的“游乐场”：Protobuf，Flatbuffers和MsgPack
02-15
序列化测试 此仓库是探索三个序列化库的“操场”，这些库是Protobuf，Flatbuffers和MsgPack。 目的是确定每个库是否适合消息密集型HPC环境中的应用程序。
FlatBufferExample:比较Flatbuffer与JSON的简短示例
05-15
Flatbuffer示例 比较Flatterbuffer与JSON的示例
Json？OR FlatBuffers?FlatBuffers
郑敏
11-03 1200
FlatBuffers in Android - introduction JSON - probably everyone knows this lightweight data format used in almost all modern servers. It weights less, is more human-readable and in general is
Apache Avro vs Apache Thrift vs Google Protocol Buffers vs MessagePack
来啊 快活啊
12-31 978
参考Apache Avro Apache Thrift Google Protocol Buffers thrift与avro RPC使用对比与总结 Apache Avro 与 Thrift 比较 Thrift、protocolbuffer、avro这几种序列化之间的比较 Protobuffer和json深度对比 跨语言通信方案的比较—Thrift、Protobuf和Avro 三种通
[译]FaceBook出品：开始用FlatBuffers替换老旧的Json吧
小黑屋
07-30 2695
加载本地缓存的时间从35ms下降到4ms； 临时内存分配减少大约75%； 冷启动时间减少10~15% 存储空间减少了15%
开源、高效、跨平台：深剖Google FlatBuffers工作原理
wblobin的博客
09-16 883
FlatBuffers是Google专为游戏开发而创建的开源、高效的跨平台序列化库，Facebook以其取代JSON来提升数据处理性能。本文作者介绍了在Android应用中使用FlatBuffers的方法，并与JSON对比，深剖FlatBuffers工作原理。 JSON——大家可能都知道它是几乎所有现代服务器都使用的轻量级数据交换格式。它体量轻，可读性强，通常比老式的、不友好
【序列化对比】Protobuf VS FlatBuffers
书山有路勤为径
10-25 5276
根据官网的介绍，FlatBuffers是一个高效的、跨平台的序列化组件，支持多种编程语言，是专门为游戏开发和其他性能关键的应用而开发的。他与Protobuf相比有什么区别呢？为什么就更适合游戏开发呢？谷歌很直接的回答了这个问题：Protobuf确实与FlatBuffers比较相似，最主要的区别就是，FlatBuffers并不需要一个转换/解包的步骤就可以获取原数据。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值