Apache Thrift和谷歌的协议缓冲区最大的优点和缺点是什么?
当前回答
正如我在“节俭vs协议缓冲区”主题中所说:
参考Thrift vs Protobuf vs JSON的比较:
Thrift supports out of the box AS3, C++, C#, D, Delphi, Go, Graphviz, Haxe, Haskell, Java, Javascript, Node.js, OCaml, Smalltalk, Typescript, Perl, PHP, Python, Ruby, ... C++, Python, Java - in-box support in 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 (btw. Here is SWI-Prolog support). Protobuf has much better documentation and plenty of examples. Thrift comes with a good tutorial Protobuf objects are smaller Protobuf is faster when using "optimize_for = SPEED" configuration Thrift has integrated RPC implementation, while for Protobuf RPC solutions are separated, but available (like Zeroc ICE ). Protobuf is released under BSD-style license Thrift is released under Apache 2 license
此外，对于这些解决方案，还有许多有趣的附加工具可用，这可能会决定。以下是Protobuf的示例:Protobuf-wireshark, protobufeditor。
其他回答
同样重要的是要注意，并非所有受支持的语言都与thrift或protobuf一致。在这一点上，除了底层序列化之外，还涉及到模块实现的问题。注意检查您计划使用的语言的基准。
正如我在“节俭vs协议缓冲区”主题中所说:
参考Thrift vs Protobuf vs JSON的比较:
Thrift supports out of the box AS3, C++, C#, D, Delphi, Go, Graphviz, Haxe, Haskell, Java, Javascript, Node.js, OCaml, Smalltalk, Typescript, Perl, PHP, Python, Ruby, ... C++, Python, Java - in-box support in 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 (btw. Here is SWI-Prolog support). Protobuf has much better documentation and plenty of examples. Thrift comes with a good tutorial Protobuf objects are smaller Protobuf is faster when using "optimize_for = SPEED" configuration Thrift has integrated RPC implementation, while for Protobuf RPC solutions are separated, but available (like Zeroc ICE ). Protobuf is released under BSD-style license Thrift is released under Apache 2 license
此外，对于这些解决方案，还有许多有趣的附加工具可用，这可能会决定。以下是Protobuf的示例:Protobuf-wireshark, protobufeditor。
我认为基本的数据结构是不同的
协议缓冲区使用变长整数，即变长数字编码，将固定长度的数字转换为变长数字以节省空间。 Thrift提出了不同类型的序列化格式(称为“协议”)。 事实上，Thrift有两种不同的JSON编码和不少于三种不同的二进制编码方法。
总之，这两个库是完全不同的。Thrift喜欢一站式服务，为您提供完整的集成RPC框架和许多选项(支持跨语言)，而Protocol Buffers更倾向于“只做一件事并做好它”。
ProtocolBuffers是fast。 这里有一个很好的基准: https://github.com/eishay/jvm-serializers/wiki(最后一次更新是2016年，但到2020年，已经有包含更快序列化器的fork，例如ActiveJ创建了一个fork来演示它们在JVM上的速度:https://github.com/activej/jvm-serializers)。
你可能还想看看Avro，它速度更快。在。net中有两个用于Avro的库:
Apache。Avro 空空的。由供应链物流公司C.H. Robinson的工程师编写
顺便说一下，我见过最快的是captain 'nProto; c#实现可以在Marc Gravell的Github-repository中找到。
协议缓冲区似乎有一个更紧凑的表示，但这只是我从阅读节俭白皮书中得到的印象。用他们自己的话来说:
我们决定反对一些极端的存储优化(即包装 小整数转换成ASCII或使用7位延续格式) 为了代码的简单性和清晰度。这些改变 当我们遇到一个性能关键的问题时，可以很容易地做出什么 需要它们的用例。
此外，这可能只是我的印象，但协议缓冲区似乎有一些更厚的抽象结构版本控制。Thrift确实提供了一些版本控制支持，但是要做到这一点需要付出一些努力。
