google protobuf
Protocol buffers are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages – Java, C++, or Python.
github：google/protobuf
google developers： protocol-buffers
Apache Thrift
The Apache Thrift software framework, for scalable cross-language services development, combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages.
github：apache/thrift
protobuf,json,xml,binary,Thrift之间的对比
一条消息数据，protobuf序列化后的大小是json的10分之一，xml格式的20分之一，是二进制序列化的10分之一，总体看来ProtoBuf的优势还是很明显的。
protobuf是google提供的一个开源序列化框架，类似于XML，JSON这样的数据表示语言。
protobuf在google中是一个比较核心的基础库，作为分布式运算涉及到大量的不同业务消息的传递，如何高效简洁的表示、操作这些业务消息在google这样的大规模应用中是至关重要的。而protobuf这样的库正好是在效率、数据大小、易用性之间取得了很好的平衡。
protobuf简单总结如下几点：
1.灵活（方便接口更新）、高效（效率经过google的优化，传输效率比普通的XML等高很多）；
2.易于使用；开发人员通过按照一定的语法定义结构化的消息格式，然后送给命令行工具，工具将自动生成相关的类，可以支持java、c++、python等语言环境。通过将这些类包含在项目中，可以很轻松的调用相关方法来完成业务消息的序列化与反序列化工作。
3.语言支持；原生支持c++,java,python
个人总结的适用protobuf的场合：
1.需要和其它系统做消息交换的，对消息大小很敏感的。那么protobuf适合了，它语言无关，消息空间相对xml和json等节省很多。
2.小数据的场合。如果你是大数据，用它并不适合。
3.项目语言是c++,java,python的，因为它们可以使用google的源生类库，序列化和反序列化的效率非常高。其它的语言需要第三方或者自己写，序列化和反序列化的效率不保证。
4.总体而言，protobuf还是非常好用的，被很多开源系统用于数据通信的工具，在google也是核心的基础库。
此外，还有更牛叉的facebook的thrift，2007年由Facebook开发，之后在2008年加到Apache计划中。是一个跨语言的轻量级RPC消息和数据交换框架，Thrift能生成的语言有: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml，这是它的一大优点。
Thrift 和 Protobuf 应用场景
在查看了一系列的资料后，觉得要从性能上的区别来在Thrift和Protobuf之间做选择意义不大，因为他们的性能太接近了。我们应该从项目支持，文档，易用性，特性方面来进行选择。如在《Thrift vs. Protocol Buffers》一文说提到的。
Thrift和Protobuf的最大不同，在于Thrift提供了完整的RPC支持，包含了Server/Client，而Protobuf只包括了stub的生成器和格式定义。
下面列出来的是一些数据交换格式的Performance测试数据，另外有两份针对Thrift和Protobuf的测试数据：
thrift-protobuf-compare ：包含了多种数据交换格式的benchmarking；
Thrift and Protocol Buffers performance in Java
Thrift and Protocol Buffers performance in Java Round 2 ：作者在对Protobuf进行了一些参数调优后重做的测试，测试结果Protobuf从带宽节省和序列化/解序列化速度上都占了优势。
数据类型
| protobuf | thrift | protobuf | thrift | protobuf | thrift | protobuf | thrift |
|---|---|---|---|---|---|---|---|
| double | double | float | byte | i16 | |||
| int32 | i32 | int64 | i64 | uint32 | uint64 | ||
| sint32 | sint64 | fixed32 | fixed64 | ||||
| sfixed32 | sfixed64 | bool | bool | string | string | ||
| bytes | binary | message | struct | enum | enum | service | service |
综合对比
| protobuf | thrift | |
| 功能特性 | 主要是一种序列化机制 | 提供了全套RPC解决方案，包括序列化机制、传输层、并发处理框架等 |
| 支持语言 | C++/Java/Python | C++, Java, Python, Ruby, Perl, PHP, C#, Erlang, Haskell |
| 易用性 | 语法类似，使用方式等类似 | |
| 生成代码的质量 | 可读性都还过得去，执行效率另测 | |
| 升级时版本兼容性 | 均支持向后兼容和向前兼容 | |
| 学习成本 | 功能单一，容易学习 | 功能丰富、学习成本高 |
| 文档&社区 | 官方文档较为丰富，google搜索protocol buffer有2000W+结果，google group被墙不能访问 | 官方文档较少，没有API文档，google搜索apache thrift仅40W结果，邮件列表不怎么活跃 |
性能对比
由于thrift功能较protobuf丰富，因此单从序列化机制上进行性能比较，按照序列化后字节数、序列化时间、反序列化时间三个指标进行，对thrift的二进制、压缩、protobuf三种格式进行对比。
测试方法：
取了15000+条样本数据，分别写了三个指标的测试程序，在自己的电脑上执行，其中时间测试循环1000次，总的序列化/反序列化次数1500W+。
平均字节数
| thrift二进制 | 535 |
| thrift压缩 | 473 |
| protobuf | 477 |
序列化（1500W次）时间（ms）：
| thrift二进制 | 306034 |
| thrift压缩 | 304256 |
| protobuf | 177652 |
反序列化（1500W次）时间（ms）：
| thrift二进制 | 287972 |
| thrift压缩 | 315991 |
| protobuf | 157192 |
thrift的时间测试可能不是很准，由于thrift产生代码的复杂性，编写的测试代码为了适应其接口，在调用堆栈上可能有一些额外开销。