Q新闻丨Facebook开源新的压缩算法，性能超zlib；来自Google的RPC框架：gRPC1.0发布

Posted 2021-05-02 InfoQ

Facebook开源新的压缩算法，性能超zlib

近日，Facebook开源了新的压缩算法Zstandard 1.0。据Facebook工程师Yann Collet和Chip Turner介绍，该算法是少数能够在性能和效率方面超过zlib的压缩算法之一，而后者当前是“占统治地位的标准”。Facebook Zstandard利用了Collet之前所做的工作。Collet是LZ4的作者，他在2015年发布了其新算法的第一个版本。

Facebook的基准测试显示，在任意压缩率和压缩带宽组合下，Zstandard的性能都要高于zlib。

特别地，当使用标准无损压缩语料库Silesia时，相比zlib，Zstandard展示了出色的性能：

• 在压缩率相同的情况下，它的速度快大约3到5倍；

• 在压缩速度相同的情况下，它生成的文件小10%到15%；

• 不管压缩率多大，它解压缩的速度都要快2倍；

• 它的最大压缩率要高许多（大约为4比3.15）。

Zstandard使用了有限状态熵，并以Jarek Duda在熵编码非对称数字系统（ANS）方面的工作为基础。ANS的目标是“避免在压缩速度和压缩率之间进行取舍”，它既可以用于精确编码，也可以用于快速编码，并且支持数据加密。但是，从根本上讲，Zstandard之所以提供了更好的性能是因为它的多项设计和实现选择。

• zlib受一个32KB的窗口限制，而Zstandard并没有任何固有的限制，它可以更充分地利用现代环境中的内存，包括移动和嵌入式环境。

• 一个新的Huffman解码器Huff0。它可以借助多个ALU并行解码符号，减少算术操作之间的依赖。

• Zstandard设法尽量减少分支，从而将因为分支预测错误而导致的、开销很高的管道清理最小化。下面的例子展示了如何在不使用分支的情况下重写while循环：

/* 经典版本 */ while (nbBitsUsed >= 8) { /* 每个while测试都是一个分支 */  accumulator <<= 8;  accumulator += *byte++;  nbBitsUsed  -= 8; } /* 无分支版本 */ nbBytesUsed = nbBitsUsed >> 3; nbBitsUsed &= 7; ptr += nbBytesUsed; accumulator = read64(ptr);

• 对于差别只有几个字节的序列，重复码建模极大地改善了压缩。

Zstandard是使用C语言编写的。它既是一个命令行工具，也是一个库。它提供了20多个压缩级别，让用户可以根据具体可用的硬件、待压缩的数据和待优化的瓶颈进行仔细地调整。Facebook建议开始时使用默认级别3。该级别适合大多数情况。然后，可以尝试9以下的级别，合理地平衡速度和空间，或者使用更高的级别获得更高的压缩率，而20以上的级别则适合那些你不关心压缩速度的情况。

对于Zstandard的未来版本会带来什么特性，Collet和Turner也提供了一些信息，其中包括支持多线程，以及可以提供更快压缩速度和更高压缩率的新的压缩级别。

Zstandard是继苹果的ZLFSE和谷歌的Brotli之后的又一个开源压缩算法。ZLFSE和Brotli都是开源的，每一种算法都针对特定的应用场景进行了优化：Brotli似乎为实现Web资产和android APK的高压缩率进行了优化，而LZFSE的目标是，在压缩率相同的情况下，提供比zlib更快的压缩速度和更低的电量消耗。

• 本文翻译已获授权，原文链接见：
  

• https://www.infoq.com/news/2016/09/facebook-zstandard-compression

• 本文译者：谢丽

来自Google的RPC框架：gRPC 1.0发布

一直以来，构建一个高度可扩展且松耦合的系统是很困难的。来自Google的gRPC框架致力于解决这个领域问题。它自去年面世以来收到了社区的大量关注和使用。8月23日Google正式发布了gRPC的1.0版本，并可用于生产。在此次发布中增加了新版本对多语言的支持、API稳定性等，引起了社区广泛的关注。

gRPC是一个高性能、开源、通用的RPC框架，它基于Proto Buffers进行数据序列化，并将移动和HTTP/2作为设计的首要考虑因素。与单一RPC请求方式不同，gPRC使用HTTP/2提供客户和服务器间的单向或双向流，同时可以带来流量控制、头部压缩、单TCP连接上的多复用请求等特性。

Google认为gRPC以“利用带宽和CPU效率、低延迟的方式来创建大规模分布式系统，可以应用在数据中心、移动应用程序、实时通信、物联网设备和API等，且有很好的表现。”而微服务是gRPC的主要目标。

gRPC最早源于被称为Stubby的Google内部项目，用于一些Google内部服务间的通信。18个月前Google开源了gRPC框架，希望借此gRPC能被更广泛地采纳，并在调用Google所提供的服务时、通过互联网与其它服务通信时或在自身产品内部应用gRPC。

gRPC是与平台无关的RPC系统。如下图所示，gRPC允许开发人员编写语言无关的服务定义，指定远程调用参数和返回类型。服务器端实现服务定义，并运行一个gRPC服务器来处理客户的调用；而客户端则部署支持客户端调用的服务器端实现存根。

这些代码都可由gRPC基于服务定义和自选的开发语言在编译器的帮助下自动生成。这使得客户端应用程序可以像调用本地对象一样调用服务器端应用程序，从而帮助开发人员更容易地创建分布式应用程序和服务。

同时，gRPC也可以帮助处理高效的网络通信、认证和访问控制（如SSL/TLS和OAuth2方式的认证）、分布式跟踪等问题。gRPC与Proto Buffers一起可以帮助实现松耦合、工程化的速度、更高的可靠性以及操作的易用性。这也是在过去的15年中，Google内部采用Stubby和RPC框架解决的问题。Google声称期望通过将这一框架开源给社区，让更多的组织和社区收益。

自2015年至今，我们也看到gRPC项目在很多方面的改进。这次1.0版本中主要包括以下几点：

• 对多种语言绑定的支持，如C ++、Java、Go、Node、Ruby、Python和C#，并且可以跨Linux、Windows和Mac多种操作系统。

• Objective-C和Android的Java库也在迁移到1.0版本，使移动应用能够更有效地连接到后端服务。

• 在安装方面，gRPC支持以CocoaPods、gem、Gradle、Maven、npm、NuGet、pecl、pip或Docker镜像等方式提供的二进制文件，这大大简化了安装过程。在1.0版本中，增加了绝大多数语言单行安装、向后兼容性等的支持。

• gRPC1.0依赖于Protocol Buffers最新版本3.0。

此外，gRPC1.0的核心协议和API在可用性、互操作性、性能等方面都有所提升。相对于文本格式而言，ProtoBuf方式可提供更优的性能。据Google工程师Kelsey Hightower介绍，ProtoBuf编码的消息比JSON格式消息的大小降低了一半，而序列化和反序列化所用的时间仅为后者的三分之一。

为了显示各种gRPC实现的通信延迟情况对比，Google给出了在同一数据中心中不同虚拟机实例间的通信性能精要报告。对于单一的同步安全消息，报告显示作为基准的Netperf的延迟大约为100微秒，而C 、Java和C#语言实现的延迟大约在200到300微秒，Ruby、Python和Node.js语言实现的延迟分别在700微秒、900微秒和1,100微秒左右。

不得不说，gRPC1.0版本的发布标志着一个重要里程碑的诞生。与此同时，社区对于gRPC的兴趣迅速提升，同时随着像Netflix、CoreOS、 Square等公司和开源项目的使用，必然能够推动gRPC作为一个通用RPC框架的发展以及相关生态圈的成熟，从而使更多的组织和社区受益。

你可以在这里（https://github.com/grpc/grpc/releases）查阅1.0版本的更多发布细节。如果你感兴趣，不妨开始尝试gRPC并通过邮件列表来给予反馈。

▽

延展阅读（点击标题）：

• 
  

• 
  

• 
  

---

喜欢我们的会点赞，爱我们的会分享！