核心特点/JDK 内置Java 原生压缩基于 算法GZIPJDK 内置基于 增加文件头和校验ZIPJDK 内置基于 支持多文件归档LZ4开源LZ4 Java极速压缩牺牲压缩率换速度开源出品追求极致速度(ZStd)开源/Meta压缩率和速度的最佳平衡开源高压缩率主要用于 Web 传输二、挨个儿进行拆解其原理以及代码实现是 2.1, 并且是 JDK 原生的“隐藏高手”。这是JDK自身所带有的压缩类, 能够直接加以使用, 其算法, 与GZip的核心算法、Zip的核心算法是一样的, 然而却减去了文件头、校验等额外产生的开销, 所以在同样的条件之下, 相较于GZip以及Zip而言, 更为高效。public static String compress(String input) { Deflater deflater new Deflater(Deflater.BEST_COMPRESSION); deflater.setInput(input.getBytes(StandardCharsets.UTF_8)); deflater.finish(); byte[] buffer new byte[512]; ByteArrayOutputStream bos new ByteArrayOutputStream(512); while (!deflater.finished()) { int len deflater.deflate(buffer); bos.write(buffer, 0, len); } deflater.end(); return Base64.getEncoder().encodeToString(bos.toByteArray()); } public static String decompress(String compressed) { byte[] data Base64.getDecoder().decode(compressed); Inflater inflater new Inflater(); inflater.setInput(data); byte[] buffer new byte[512]; ByteArrayOutputStream bos new ByteArrayOutputStream(512); while (!inflater.finished()) { int len inflater.inflate(buffer); bos.write(buffer, 0, len); } inflater.end(); return bos.toString(UTF-8); }关键参数如下, 压缩等级从0至9是能够进行调节的, 当等于9的时候, 其压缩比率是最高的, 不过速度却是最慢的, 而当等于1的时候, 速度是最快的, 然而压缩比率却比较低。2.2 GZIP —— 最经典的压缩方案GZIP 其本质是, 算法与 GZIP 文件头以及 CRC32 校验的组合。由于存在文件头和尾部校验信息, 在相同数据的情况下, 经压缩后的体积相较于单纯的, 要略大一些。public static String gzipCompress(String str) { ByteArrayOutputStream bos new ByteArrayOutputStream(); try (GZIPOutputStream gzip new GZIPOutputStream(bos)) { gzip.write(str.getBytes(StandardCharsets.UTF_8)); } return Base64.getEncoder().encodeToString(bos.toByteArray()); } public static String gzipDecompress(String compressed) { byte[] data Base64.getDecoder().decode(compressed); ByteArrayInputStream bis new ByteArrayInputStream(data); try (GZIPInputStream gis new GZIPInputStream(bis)) { ByteArrayOutputStream bos new ByteArrayOutputStream(); byte[] buffer new byte[1024]; int len; while ((len gis.read(buffer)) ! -1) { bos.write(buffer, 0, len); } return bos.toString(UTF-8); } }长处在于, 通用性极其强, 差不多所有的语言以及系统都原生实施支持, 适宜数据存在需要跨越平台进行传输的情景。2.3 ZIP —— 支持多文件的压缩格式ZIP在原本范围之外增添了概念, 此概念能够对多个文件予以管理。然而若仅是对单个字符串实施压缩, 那额外的Entry元信息反倒致使开销有所增加。public static String zipCompress(String str) { ByteArrayOutputStream bos new ByteArrayOutputStream(); try (ZipOutputStream zos new ZipOutputStream(bos)) { zos.putNextEntry(new ZipEntry(data)); zos.write(str.getBytes(StandardCharsets.UTF_8)); zos.closeEntry(); } return Base64.getEncoder().encodeToString(bos.toByteArray()); }结论是, 针对于单字符串压缩, ZIP属于最差的选择, 因为Entry元数据增添了没必要的体积。2.4 LZ4 —— 极速之王LZ4是由Yann设计的, 其核心目标在于极致的压缩速度, 以及极致的解压速度, 而压缩率相对来说是次要的。// 依赖org.lz4:lz4-java public static byte[] lz4Compress(byte[] data) { LZ4Compressor compressor LZ4Factory.fastestInstance().fastCompressor(); int maxLen compressor.maxCompressedLength(data.length); byte[] compressed new byte[maxLen]; int len compressor.compress(data, 0, data.length, compressed, 0, maxLen); return Arrays.copyOf(compressed, len); }该方案具备这样的特性, 其解压的具体速度能够达到每秒三千八百五十兆字节, 在所有的方案当中, 它的解压速度是最为快速的, 此特性适用于那种对于延迟有着极高要求, 极其敏感的实时系统。2.5 —— 的高性能方案该压缩算法乃是专门为特定需求所设计的, 其目标在于, 在确保处于合理范围之内的压缩率的情形下, 达成能够实现的最高强度的吞吐量。// 依赖org.xerial.snappy:snappy-java public static byte[] snappyCompress(byte[] data) throws IOException { return Snappy.compress(data); }作为 Kafka 默认压缩算法之一, 它有着代码极简的特点, 其压缩速度大约在 520 MB/s 左右, 解压速度大概处在约 1500 MB/s 的水平。2.6 (ZStd) —— 全能王者ZStd, 也就是说现在的Meta这个主体所开源的压缩算法, 它能给出自超快速度到最大极限压缩率的一个较为宽广的可调节幅度范围, 并且在所有给出的压缩级别状况下其解压的速度始终维持在稳定状态。// 依赖com.github.luben:zstd-jni public static byte[] zstdCompress(byte[] data) { return Zstd.compress(data); } public static byte[] zstdDecompress(byte[] compressed) { long originalSize Zstd.decompressedSize(compressed); byte[] result new byte[(int) originalSize]; Zstd.decompress(result, compressed); return result; }官方基准测试数据能看到的是, ZStd Level 1有着比GZip要高5.6%的压缩率, 然而其压缩速度快上了差不多5倍, 解压速度快出了4倍。2.7 —— Web 传输的压缩利器是的一种作为推出体现的特定压缩算法成果, 其主要被加以利用的场景领域为HTTP传输情形, 具体而言是带有字符指向含义及括号表示的这种情况里, 在Web所涉及的场景范畴之下, 相较于GZip而言, 其具备大约小了15%至25%这样幅度的特点。// 依赖org.brotli:dec / com.nixxcode.jvmbrotli:jvmbrotli public static byte[] brotliCompress(byte[] data) { // 通过 BrotliEncoder 进行压缩 Encoder.Parameters params new Encoder.Parameters(); return Encoder.compress(data, params); }拥有这样的特点, 压缩率是极其高的, 然而呢, 压缩速度却是比较慢的。它主要是面向涉及“一回次压缩, 多次进行传输”的那种Web静态资源场景。三、实测对比用数据说话进行实测时, 我们采用一段约5000字符的JSON文本, 编码后予以统一衡量:注意, 数据是经过多次测试后选取平均值得到的, 实际上因为数据所具有的特征, 也就是文本类型及重复度方面, 结果会存在差异。关键发现的压缩率排名情况是, 大于ZStd大于GZIP, 大于ZIP, 大于LZ4 , 压缩速度排名是, LZ4大于, 大于ZStd, 大于GZIP, 大于ZIP , 解压速度排名是, LZ4大于, 大于ZStd, 大于GZIP , 还有四、深度分析, 为什么结果是这样的呢? 4.1 与GZIP与ZIP比较同宗不同命。三者都基于 算法但包装不同所以, 在对单个字符串开展压缩操作的时候, GZIP的压缩效果要优于ZIP, 这里“”所表达的意思就是压缩效果更佳。4.2 LZ4 vs —— 速度之争LZ4 和 都是高速低压缩率路线但设计哲学不同这两者的压缩率, 都处于大概从40%到45%这样的范围, 并无较高的数值表现, 因此是不适合那种对于存储空间有着敏感特性的场景的。4.3 ZStd —— 为什么它被称为全能王者ZStd具备独特之处, 此独特之处在于它针对那一个参数空间予以提供, 该参数空间是从速度起始一直到压缩率的, 且是连续可调的。更为关键之处在于, 解压的速度, 于所有的压缩级别范围之内, 大体都是保持不变的状况大约为1500 MB/s, 这所意谓的是, 你能够安心地去运用高压缩级别以便节省存储空间, 而无需为此担忧解压性能会出现下降的情况。这同样堪称有着这般情况的缘故, Linux内核、MySQL、Kafka等重要程度上较为突出的项目, 均都做出了选择ZStd 如此的决定。4.4 —— 高压缩率的代价采用了更为繁杂的算法, 此算法包含二次上下文建模以及编码, 虽其压缩率的确是最高的, 然而其压缩速度十足地缓慢。它特别适宜的场景乃是“一次进行压缩, 千万次予以传输”的网络静态资源, 并不契合需要频繁开展压缩的实时场景。五、场景选型指南根据以上分析我总结了一份选型决策表场景 1Redis 缓存大文本推荐ZStd 或Redis所存储的是内存方面的数据, 既要做到节省空间, 同时又不能够缓慢。ZStd Level 3在压缩比率以及速度之间达成了很好的平衡。要是不想引入第三方依赖, JDK原生的同样是不错的选择。场景 2网络传输高频次、小数据包推荐 或 LZ4最怕延迟的是网络传输, LZ4的解压速度最快, 压缩速度同样最快, 适用于对延迟极为敏感的RPC场景, 也适用于对延迟极为敏感的消息队列场景, 在Kafka中已被验证多年, 是可靠的选择。场景 3数据库存储低频写入、高频读取推荐ZStd 高压缩级别在数据库这一特定场景当中, 数据一旦被写入, 便有可能会被读取千百回之多。ZStd所具备的极高压缩级别, 能够在很大程度上节省存储空间, 并且解压的速度基本上不会受到什么影响。场景 4HTTP 响应压缩推荐 或 GZIP存在于所有主流浏览器当中都已经被予以支持的情况, 其压缩率要比 GZip 高出 15%至 25%, 适用于对 API 响应以及静态资源进行压缩。而 GZip 作为一种兜底方案, 它的兼容性是最佳的。场景 5日志归档推荐ZStd 或 GZIP具备大量日志数据, 且其重复程度较高, 在此情形下, 它的压缩效果十分显著。ZStd Level 19能够把日志的体积压缩至极小的状态。要是有更广泛的工具兼容性需求比如, 那么选择使用GZip也是可行的。场景 6不想引入第三方依赖推荐JDK原生的, 不存在依赖情况, 其压缩率在仅次于ZStd的行列之中, 并且, 对于中小规模的应用而言, 完全能够满足使用需求。六、进阶技巧6.1 小数据的压缩陷阱在数据量处于极其微小的情形时具体而言像小于256字节这样, 进行压缩操作反倒极有可能致使数据的规模变大。这是由于压缩算法在运行过程当中需要对元数据涵盖字典、表等各类形式予以存储, 而这些所产生的开销在针对小数据进行处理时占据的比例是非常高的。有这样一个建议, 当数据的长度是小于 256 字节的情况时, 不要进行压缩。ZStd 的字典模式能够借助预训练去解决小数据压缩方面的问题, 它是适合那种批量处理同类型数据的场景的。6.2 编码的额外开销在文本环境像JSON、XML领域似的范畴那儿进行安全的传传输之时候, 被压缩过后的二进制数据通常是需要被编码一番的, 然而, 这样做会致使数据所占据的体积增加大概为33%。倘若传输环境对二进制予以支持像是gRPC、Redis safe这种情况, 那么应当直接去存储经过压缩的二进制数据, 并且予以跳过处理。6.3 压缩级别调优不要毫无思考地运用最高压缩级别, 拿 ZStd 来说, 当处于 Level 3 至 Level 19 时, 压缩率或许仅仅提高了 10%到 15%, 然而压缩所花费的时间有可能比之前增加达 10 倍以上。建议, 在多数场景之中, ZStd Level 1至3乃是最优之选, 唯有于存储成本远高于计算成本的场景里面, 方才值得运用高压缩级别。七、总结要是仅能够记住一句话, 那就是平常应用 ZStd, 追求速度时采用 LZ4, 而需零依赖时使用。对于压缩算法的挑选, 实际上是于压缩率、速度以及兼容性这三者相互之间进行权衡。不存在所谓的“万能算法”, 仅仅存在“最契合当下场景的算法”。要明白每种算法所具有的特性, 这样才能够在进行技术选型的时候, 做出明智的抉择, 而并非一直停留在“仅仅使用 GZip 就可以了”这种状态。这句话基于Java 8以上的环境, 数据源自实际测试以及ZStd官方基准测试, 由于测试环境不一样, 数据特征也不同, 所以结果有可能存在差异, 仅作参考用。