节俭与协议缓冲最大的区别是什么？
Apache Thrift vs Google Protocol Buffers的最大利弊是什么？
他们都提供许多相同的function; 但是，有一些差异：
- 节俭支持“例外”
- 协议缓冲区有更好的文档/例子
- 节俭有一个内置的
Settypes - 协议缓冲区允许“扩展” – 您可以扩展外部协议来添加额外的字段，同时仍然允许外部代码对这些值进行操作。 在节俭中没有办法做到这一点
- 我发现Protocol Buffers更容易阅读
基本上，它们是相当的（与我读过的协议缓冲器稍微有效率）。
另一个重要区别是默认支持的语言。
- 协议缓冲区：Java，Android Java，C ++，Python，Ruby，C＃，Go，Objective-C，Node.js
- Thrift：Java，C ++，Python，Ruby，C＃，Go，Objective-C，JavaScript，Node.js，Erlang，PHP，Perl，Haskell，Smalltalk，OCaml，Delphi，D，Haxe
两者都可以扩展到其他平台，但是这些是可以立即使用的语言绑定。
RPC是另一个关键的区别。 Thrift生成代码来实现RPC客户端和服务器，而协议缓冲区似乎大部分被devise为单独的数据交换格式。
- Protobuf序列化对象比Thrift小约30％。
- 除非您打开
option optimize_for = SPEED否则您可能想要使用protobuf对象（创build，序列化，反序列化）的大部分操作要比节俭慢得多 。 - 节俭有更丰富的数据结构（地图，设置）
- Protobuf API看起来比较干净，虽然生成的类都被封装成内部类，但并不是那么好。
- Thrift枚举不是真正的Java枚举，即它们只是整数。 Protobuf有真正的Java枚举。
仔细看看差异，看看这个开源项目的源代码差异。
正如我所说的“节约vs协议缓冲”主题：
提到节俭与Protobuf与JSON比较 ：
- Thrift支持开箱即用的AS3，C ++，C＃，D，Delphi，Go，Graphviz，Haxe，Haskell，Java，Javascript，Node.js，OCaml，Smalltalk，Typescript，Perl，PHP，Python，Ruby，…
- C ++，Python，Java支持Protobuf
- Protobuf支持其他语言（包括Lua，Matlab，Ruby，Perl，R，Php，OCaml，Mercury，Erlang，Go，D，Lisp）作为第三方插件 （顺便说一句， 这是SWI-Prolog的支持 ）。
- Protobuf有更好的文档和大量的例子。
- 节俭来一个很好的教程
- Protobuf对象较小
- 解除“optimize_for = SPEED”时，Protobuf会更快
- Thrift集成了RPC实现，而对于Protobuf RPC解决scheme是分开的，但是可用 （如Zeroc ICE ）。
- Protobuf是在BSD风格的许可下发布的
- 节俭是在Apache 2许可下发布的
另外，这些解决scheme还有很多有趣的附加工具可供select。 以下是Protobuf的示例： Protobuf-wireshark ， protobufeditor 。
与Python上的protobuff相比，我能够使用基于文本的协议获得更好的性能。 但是，没有types检查或其他奇特的utf8转换等… protobuff提供。
所以，如果你需要序列化/反序列化，那么你可以使用别的东西。
http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html
Protocol Buffers似乎有一个更紧凑的表示forms，但这只是我从阅读Thrift白皮书中得到的印象。 用他们自己的话说：
为了简化和清晰起见，我们决定不要进行一些极端的存储优化（即将小整数转换为ASCII或使用7位连续格式）。 当我们遇到需要它们的性能关键用例时，可以很容易地做出这些改变。
另外，这可能只是我的印象，但是协议缓冲区似乎在结构版本化方面有一些较厚的抽象。 节俭确实有一些版本支持，但需要一点努力才能实现。
还没有提到的一个明显的事情是，既可以是专业也可以是con（两者都是相同的）是它们是二进制协议。 这允许更紧凑的表示和可能更多的性能（优点），但是具有降低的可读性（或者说，可debugging性），con。
另外，两者都比标准格式（比如xml）（甚至可能是json）要less一些工具支持。
（编辑）这是一个有趣的比较 ，处理大小和性能差异，并包括一些其他格式（XML，JSON）的数字。
而根据wiki ，Thrift运行时不能在Windows上运行。
ProtocolBuffers是更快。
这里有一个很好的基准：
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
你可能也想看看Avro，因为Avro更快。
微软在这里有一个包：
http://www.nuget.org/packages/Microsoft.Hadoop.Avro
顺便说一下，我见过的最快的是Cap'nProto ;
AC＃实现可以在Marc Gravell的Github库中find。
我认为这些观点中的大部分已经错过了Thrift是一个RPC框架的基本事实，它恰好能够使用各种方法（二进制，XML等）来序列化数据。
协议缓冲区纯粹是为了序列化而devise的，它不像Thrift这样的框架。
这里有一些优秀的点子，我要添加一个，以防某些人的path在这里穿越。
Thrift给你一个在thrift-binary和thrift-compact（de）序列化程序之间进行select的选项，thrift-binary会有一个很好的性能，但是包的大小更大，而thrift-compact会给你很好的压缩，但是需要更多的处理能力。 这很方便，因为你可以随时在这两个模式之间切换，就像改变一行代码一样（甚至可以configuration）。 所以如果你不确定你的应用程序应该为数据包大小或处理能力优化多less，节俭可能是一个有趣的select。
PS：通过比较包括thrift-binary，thrift-compact和protobuf在内的许多序列化thekvs ，看看这个优秀的基准testing项目： https ： //github.com/thekvs/cpp-serializers
PS：还有另一个名为YAS序列化程序，它也提供了这个选项，但是它没有模式，请参阅上面的链接。
