Apache Thrift vs Google's Protocol Buffers的最大利弊是什么？
它们都提供许多相同的功能;但是，存在一些差异：
Thrift支持'exceptions'
Protocol Buffers有更好的文档/示例
Thrift有一个内置的 Set 类型
Set
协议缓冲区允许"extensions" - 您可以扩展外部协议以添加额外字段，同时仍允许外部代码对值进行操作 . 在Thrift中没有办法做到这一点
我发现协议缓冲区更容易阅读
基本上，它们是相当等效的（协议缓冲区比我读过的更有效） .
另一个重要区别是默认支持的语言 .
协议缓冲区：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客户端和服务器，而协议缓冲区似乎主要设计为数据交换格式 .
Protobuf序列化对象比Thrift小约30％ .
除非打开option optimize_for = SPEED，否则您可能想要对protobuf对象（创建，序列化，反序列化）执行的大多数操作都是much slower than thrift .
Thrift拥有更丰富的数据结构（Map，Set）
Protobuf API看起来更干净，虽然生成的类都被打包为内部类，但不是很好 .
Thrift枚举不是真正的Java Enum，即它们只是整数 . Protobuf有真正的Java枚举 .
要仔细查看差异，请查看this open source project处的源代码差异 .
正如我所说"Thrift vs Protocol buffers"主题：
参考Thrift vs Protobuf vs JSON comparison：
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 support for other languages (including Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) is available as Third Party Addons（顺便说一句Here is SWI-Prolog support） .
Protobuf有更好的文档和大量的例子 .
Thrift附带一个好tutorial
Protobuf对象较小
Protobuf在取消时更快"optimize_for = SPEED"
Thrift集成了RPC实现，而Protobuf RPC solutions are separated, but available（如Zeroc ICE） .
Protobuf是在BSD风格的许可下发布的
Thrift在Apache 2许可下发布
此外，还有许多有趣的附加工具可供这些解决方案使用，这些工具可能会决定 . 以下是Protobuf的示例：Protobuf-wireshark，protobufeditor .
与python上的protobuff相比，我能够通过基于文本的协议获得更好的性能 . 但是，没有类型检查或其他花哨的utf8转换等... protobuff提供 .
因此，如果您只需要序列化/反序列化，那么您可以使用其他东西 .
http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html
协议缓冲区似乎有一个更紧凑的表示，但这只是我从阅读Thrift白皮书得到的印象 . 用他们自己的话说：
为了代码中的简单和清晰起见，我们决定不进行一些极端的存储优化（即将小整数打包成ASCII或使用7位连续格式） . 当我们遇到需要它们的性能关键用例时，可以轻松地进行这些更改 .
此外，它可能只是我的印象，但协议缓冲区似乎有一些较厚的抽象结构版本 . Thrift确实有一些版本支持，但需要花费一些力气才能实现 .
一个显而易见的事情是，无论是pro还是con（两者都相同）都是二进制协议 . 这允许更紧凑的表示和可能更多的性能（专业），但是具有降低的可读性（或者更确切地说，可调试性），con .
此外，两者都比标准格式（如xml（甚至可能是json））具有更少的工具支持 .
（编辑）这是一个Interesting comparison，它解决了大小和性能差异，并包括一些其他格式（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;可以在Github-repository of Marc Gravell找到C＃实现 .
我认为大多数这些观点都错过了Thrift是一个RPC框架的基本事实，它恰好具有使用各种方法（二进制，XML等）序列化数据的能力 .
协议缓冲区纯粹是为了序列化而设计的，它不是像Thrift这样的框架 .
首先，protobuf不是完整的RPC实现 . 它需要像gRPC这样的东西 .
与Thrift相比，gPRC非常缓慢：
http://szelei.me/rpc-benchmark-part1/
这里有一些优点，我将添加另一个，以防有人的路径穿过这里 .
Thrift为您提供了在thrift-binary和thrift-compact（de）序列化程序之间进行选择的选项，thrift-binary将具有出色的性能但是更大的数据包大小，而thrift-compact将为您提供良好的压缩但需要更多的处理能力 . 这很方便，因为您可以像更改一行代码一样轻松地在这两种模式之间切换（哎呀，甚至可以配置它） . 因此，如果您不确定您的应用程序应针对数据包大小或处理能力进行优化多少，那么节俭可能是一个有趣的选择 .
PS：通过 thekvs 查看这个优秀的基准测试项目，它比较了许多序列化器，包括thrift-binary，thrift-compact和protobuf：https://github.com/thekvs/cpp-serializers
thekvs
PS：还有另一个名为 YAS 的序列化程序，它也提供了这个选项，但它没有模式，请参阅上面的链接 .
YAS
值得注意的是，并非所有受支持的语言都与thrift或protobuf一致 . 此时，除了底层序列化之外，它还是模块实现的问题 . 请注意检查您计划使用的任何语言的基准 .
14 回答
它们都提供许多相同的功能;但是，存在一些差异：
Thrift支持'exceptions'
Protocol Buffers有更好的文档/示例
Thrift有一个内置的
Set类型协议缓冲区允许"extensions" - 您可以扩展外部协议以添加额外字段，同时仍允许外部代码对值进行操作 . 在Thrift中没有办法做到这一点
我发现协议缓冲区更容易阅读
基本上，它们是相当等效的（协议缓冲区比我读过的更有效） .
另一个重要区别是默认支持的语言 .
协议缓冲区：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客户端和服务器，而协议缓冲区似乎主要设计为数据交换格式 .
Protobuf序列化对象比Thrift小约30％ .
除非打开option optimize_for = SPEED，否则您可能想要对protobuf对象（创建，序列化，反序列化）执行的大多数操作都是much slower than thrift .
Thrift拥有更丰富的数据结构（Map，Set）
Protobuf API看起来更干净，虽然生成的类都被打包为内部类，但不是很好 .
Thrift枚举不是真正的Java Enum，即它们只是整数 . Protobuf有真正的Java枚举 .
要仔细查看差异，请查看this open source project处的源代码差异 .
正如我所说"Thrift vs Protocol buffers"主题：
参考Thrift vs Protobuf vs JSON comparison：
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 support for other languages (including Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) is available as Third Party Addons（顺便说一句Here is SWI-Prolog support） .
Protobuf有更好的文档和大量的例子 .
Thrift附带一个好tutorial
Protobuf对象较小
Protobuf在取消时更快"optimize_for = SPEED"
Thrift集成了RPC实现，而Protobuf RPC solutions are separated, but available（如Zeroc ICE） .
Protobuf是在BSD风格的许可下发布的
Thrift在Apache 2许可下发布
此外，还有许多有趣的附加工具可供这些解决方案使用，这些工具可能会决定 . 以下是Protobuf的示例：Protobuf-wireshark，protobufeditor .
与python上的protobuff相比，我能够通过基于文本的协议获得更好的性能 . 但是，没有类型检查或其他花哨的utf8转换等... protobuff提供 .
因此，如果您只需要序列化/反序列化，那么您可以使用其他东西 .
http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html
协议缓冲区似乎有一个更紧凑的表示，但这只是我从阅读Thrift白皮书得到的印象 . 用他们自己的话说：
此外，它可能只是我的印象，但协议缓冲区似乎有一些较厚的抽象结构版本 . Thrift确实有一些版本支持，但需要花费一些力气才能实现 .
一个显而易见的事情是，无论是pro还是con（两者都相同）都是二进制协议 . 这允许更紧凑的表示和可能更多的性能（专业），但是具有降低的可读性（或者更确切地说，可调试性），con .
此外，两者都比标准格式（如xml（甚至可能是json））具有更少的工具支持 .
（编辑）这是一个Interesting comparison，它解决了大小和性能差异，并包括一些其他格式（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;
可以在Github-repository of Marc Gravell找到C＃实现 .
我认为大多数这些观点都错过了Thrift是一个RPC框架的基本事实，它恰好具有使用各种方法（二进制，XML等）序列化数据的能力 .
协议缓冲区纯粹是为了序列化而设计的，它不是像Thrift这样的框架 .
首先，protobuf不是完整的RPC实现 . 它需要像gRPC这样的东西 .
与Thrift相比，gPRC非常缓慢：
http://szelei.me/rpc-benchmark-part1/
这里有一些优点，我将添加另一个，以防有人的路径穿过这里 .
Thrift为您提供了在thrift-binary和thrift-compact（de）序列化程序之间进行选择的选项，thrift-binary将具有出色的性能但是更大的数据包大小，而thrift-compact将为您提供良好的压缩但需要更多的处理能力 . 这很方便，因为您可以像更改一行代码一样轻松地在这两种模式之间切换（哎呀，甚至可以配置它） . 因此，如果您不确定您的应用程序应针对数据包大小或处理能力进行优化多少，那么节俭可能是一个有趣的选择 .
PS：通过
thekvs查看这个优秀的基准测试项目，它比较了许多序列化器，包括thrift-binary，thrift-compact和protobuf：https://github.com/thekvs/cpp-serializersPS：还有另一个名为
YAS的序列化程序，它也提供了这个选项，但它没有模式，请参阅上面的链接 .值得注意的是，并非所有受支持的语言都与thrift或protobuf一致 . 此时，除了底层序列化之外，它还是模块实现的问题 . 请注意检查您计划使用的任何语言的基准 .