Thrift、protocolbuffer、avro这几种序列化之间的比较
一.概述
thrift和avro都提供rpc服务和序列化，而protocol buffer只是提供序列化功能。
thrift是一个跨语言的轻量级RPC消息和数据交换框架，Thrift能生成的语言有: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml。
Avro是强调一种高效的序列化，标准性的云计算的数据交换和存储的Protocol，Avro的创新之处在于融合了显式,declarative的Schema和高效二进制的数据表达，强调数据的自我描述，克服了以往单纯XML或二进制系统的缺陷。
Avro对Schema动态加载功能，是Thrift编程接口所不具备的，符合了Hadoop上的Hive/Pig及NOSQL 等既属于ad hoc，又追求性能的应用需求。
二.protobuf
一条消息数据，用protobuf序列化后的大小是json的10分之一，xml格式的20分之一，是二进制序列化的10分之一，总体看来ProtoBuf的优势还是很明显的。
protobuf是google提供的一个开源序列化框架，类似于XML，JSON这样的数据表示语言，详情访问protobuf的google官方网站。
protobuf在google中是一个比较核心的基础库，作为分布式运算涉及到大量的不同业务消息的传递，如何高效简洁的表示、操作这些业务消息在google这样的大规模应用中是至关重要的。而protobuf这样的库正好是在效率、数据大小、易用性之间取得了很好的平衡。
1.protobuf简单总结
a.灵活（方便接口更新）、高效（效率经过google的优化，传输效率比普通的XML等高很多）；
b.易于使用；开发人员通过按照一定的语法定义结构化的消息格式，然后送给命令行工具，工具将自动生成相关的类，可以支持java、c++、python等语言环境。通过将这些类包含在项目中，可以很轻松的调用相关方法来完成业务消息的序列化与反序列化工作。
c.语言支持；原生支持c++,java,python
2.个人总结的适用protobuf的场合
a.需要和其它系统做消息交换的，对消息大小很敏感的。那么protobuf适合了，它语言无关，消息空间相对xml和json等节省很多。
b.小数据的场合。如果你是大数据，用它并不适合。
c.项目语言是c++,java,python的，因为它们可以使用google的源生类库，序列化和反序列化的效率非常高。其它的语言需要第三方或者自己写，序列化和反序列化的效率不保证。
d.总体而言，protobuf还是非常好用的，被很多开源系统用于数据通信的工具，在google也是核心的基础库。
三.Thrift和avro比较
1.Schema处理
a.thrift依赖IDL-->代码的生成，静态的。走代码生成，编译载入的流程。
b.可以生成代码，后编译执行，但是还必须依赖IDL（meta元数据描述）；也可以走动态解释执行IDL
2.序列化的方式
a.thrift提供多种序列化实现，TCompactProtocol，TBinaryProtocol，每个Field前面都是带Tag的，这个Tag用于标识这个域的类型和顺序ID（IDL中定义，用于Versioning）。在同一批数据里面，这些Tag的信息是完全相同的，当数据条数大的时候这显然就浪费了。
b.Avro，格式包括--》文件头中有schema+数据records(自描述)
只对感兴趣的部分反序列化
schema允许定义数据的排序order
采用block链表结构，突破了用单一整型表示大小的限制。比如Array或Map由一系列Block组成，每个Block包含计数器和对应的元 素，计数器为0标识结束。
3.RPC的服务
a.Avro提供了
HttpServer : 缺省,基于Jetty内核的服务
NettyServer: 新的基于Netty的服务
b.Thrift提供了：
TThreadPolServer: 多线程服务
TNonBlockingServer: 单线程 non blocking的服务
THsHaServer: 多线程 non blocking的服务
四.总结
Thrift适用于程序对程序静态的数据交换，要求schema预知并相对固定；
Avro在Thrift基础上增加了对schema动态的支持且性能上不输于Thrift；
Avro显式schema设计使它更适用于搭建数据交换及存储的通用工具和平台,特别是在后台；
目前Thrift的优势在于更多的语言支持和相对成熟；
PB具有跨平台、解析速度快、序列化数据体积小、扩展性高、使用简单的特点，但是内嵌并没有提供RPC的通讯。
文章来源：