zstandard

背景 通常而言，服务发布平台的构建部署的流程（镜像部署除外）会经过 构建 （同步代码 -> 编译 -> 打包 -> 上传）、 部署 （下载包 -> 解压到目标机器 -> 重启服务）等步骤。以美团内部的发布平台 Plus 为例，最近我们发现一些发布项在构建产物打包压缩的过程中耗时比较久。如下图所示的 pack 步骤，一共消耗了1分23秒。 而在平常为用户解答运维问题的时候我们也发现，很多用户会习惯将一些较大的机器学习或者 NLP 相关的数据放入到仓库中，这部分数据往往占据几百兆，甚至占据几个GB的磁盘空间，十分影响打包的速度。 Java 项目也是如此，由于 Java 服务框架繁多，依赖也多，通常这些服务打包后也要占据百兆级别的空间，耗时也会达到十多秒。下图是我们的 pack 步骤的中位数，基本上大部分的 Java 服务和 Node.js 服务都至少要消耗 13s 左右的时间来做压缩打包 。 pack 作为几乎所有需要部署的服务必需步骤，它目前的耗时基本上仅低于编译和构建镜像，因此，为了提高整体构建的效率，我们准备对 pack 打包压缩的步骤进行一轮优化工作。 方案对比 准备场景数据 发布项的包大小分析 为了尽可能地模拟构建部署中的应用场景，我们将 2020 年的部分 构建包数据 进行了整理分析，其中压缩后的包大小如下图所示，钟形曲线说明了整体的包体积呈正态分布

前言 在我们日常使用计算机的时候，经常会遇到或者使用一些文件，它们通常以 .zip ， .rar ， .7z 结尾，这些文件就是本文所说的压缩文件，我们可以通过资源管理器，WinRAR，WinZip，或者 7-zip 将其解压，然后查看，编辑，或者进行其他操作。压缩软件被广泛运用于文件分享，软件分发，或作为一个容器承载其他文件集合，比如我们如果使用 Office 2007 以及更高的版本保存 Word/PPT/Excel 文档时，这些文档实际上就是特殊的 ZIP 压缩文件，Word/PPT/Excel 的格式实际上就是将描述元素（文本框，标题...） 信息的 XML 文件，以及一些资源文件使用 Deflate(Fastest) 压缩算法压缩到一个 ZIP 格式文件中。还有 Java 程序员需要经常见到的 Jar 包，Android 开发者打包的 APK 文件，以及 Windows 开发者创建的 Appx(以及 MSIX) 安装包，这些文件都是压缩文件，准确的说，这几种都是 ZIP 压缩文件。 压缩软件的格式非常多，有 ZIP，RAR，7Z，TAR，CAB 等等，其中 ZIP 是运用最广泛的压缩文件格式，而在 Unix 世界 TAR 则更受欢迎。探讨文件的压缩实际上是个有趣的过程，而本文也就是对压缩文件进行一个胡乱的分析。 常见的文件压缩格式比较 ZIP 轶闻和现状 如果我们使用

背景 保证kafka高吞吐量的另外一大利器就是消息压缩。就像上图中的压缩饼干。 压缩即空间换时间，通过空间的压缩带来速度的提升，即通过少量的cpu消耗来减少磁盘和网络传输的io。 消息压缩模型 消息格式V1 kafka不会直接操作单条消息，而是直接操作一个消息集合。 消息格式V2: 1, 抽取了消息的公共部分放到消息集合中；去掉每条消息的公共部分，减少了总体积。 2，消息的CRC校验由对每一条消息，移动到了对消息集合进行校验，减少了校验次数，节省了cpu; 3, 对单个消息进行压缩，放到消息的body字段 pk 对消息集合整个进行压缩 更好的压缩效果； 压缩过程模型 压缩算法比较 如何衡量一个压缩算法的好坏。 常见的压缩算法对比： Zstandard 算法（简写为 zstd）。它是 Facebook 开源的一个压缩算法，能够提供超高的压缩比 启用压缩场景 如果cpu负载比较高，不适合启用压缩； 如果带宽不足，而cpu负载不高，最适合启用压缩，节约大量的带宽； 尽量避免消息格式不一致带来的解压缩消耗。 小结 压缩的目的是较少空间占用，带来传输速度的提升，但是需要消耗一定的cpu ； 是一种提高kafka消息吞吐量的有效办法。 本节回顾了新版的kafka是如何对消息进行压缩的，压缩和解压缩的流程是怎样的， 然后对比了常见的4种压缩算法，根据具体的使用场景来选择是否启用压缩