压缩是计算机系统中无处不在的基础设施技术。从网络传输到磁盘存储，从日志处理到消息队列，压缩算法直接影响着系统的吞吐量与成本。在规模化场景下，压缩率的微小提升都可能转化为可观的成本节约。本文将从工程实现角度，深入解析主流无损压缩算法的核心机制、时空权衡特性以及可调参数，为开发者提供可操作的参数配置指南。
压缩基础与算法分类
压缩的本质是用更少的比特表示原始数据。根据信息论，数据的冗余度决定了压缩的上限。工程实践中，无损压缩主要依赖三大基础技术：游程编码（Run-Length Encoding，RLE）、字典编码（Lempel-Ziv 系列）和熵编码（Huffman、ANS）。
游程编码是最简单的压缩方式，将连续出现的相同元素替换为单个元素加计数的组合。例如 AAAAAAAA 可以表示为 6A。这种方式对重复性高的数据（如位图）效果显著，但对一般文本数据效果有限。
Lempel-Ziv 系列（简称 LZ）是现代压缩算法的核心框架。LZ77 于 1977 年提出，使用滑动窗口和回引用的方式：当前位置的序列如果曾在之前出现过，则用一组位置偏移和长度来引用它。例如「This is a nice sweet example of LZ, a nice sweet example of LZ」可以压缩为「This is a nice sweet example of LZ, <28, 26>」，表示向前回退 28 个字符并复制 26 个字符。这种基于重复模式的编码方式构成了 DEFLATE（gzip）、Snappy、LZ4、ZSTD 等主流算法的底层框架。
熵编码根据符号出现的频率分配不同长度的编码。Huffman 编码是最经典的实现：出现频率高的符号用短码，频率低的用长码。在英文文本中，字母 e 出现频率最高，应分配最短编码；字母 z 出现频率最低，使用较长编码也不会造成显著开销。
DEFLATE 算法工程细节
DEFLATE 是 gzip、ZIP、DOCX、PNG 等广泛使用的压缩格式的核心算法。它实际上是 LZ77 与 Huffman 编码的组合：首先通过 LZ77 找出重复序列并替换为回引用，然后对结果进行 Huffman 编码以进一步压缩。
DEFLATE 的块结构设计体现了工程权衡的智慧。块类型 0 用于存储无法被压缩的数据（如随机数），直接输出原字节以避免压缩反而增大体积的情况。块类型 1 使用预定义的固定 Huffman 编码，解码速度快但压缩率低。块类型 2 为每个数据块构建自定义 Huffman 树，根据实际符号频率优化编码，能获得最佳压缩率但需要额外传输编码表。
在 LZ77 实现层面，RFC 建议使用链式哈希表来加速回引用查找。哈希函数的选取直接影响碰撞率和查找效率。Go 语言标准库采用常数值 0x1e35a7bd 作为乘数，这是一个经过实验验证的最优常量，能够有效分散哈希值的位分布。实现中通常对连续 4 字节进行哈希，而非 RFC 建议的 3 字节，以降低碰撞概率。
压缩级别的参数设计体现了典型的工程权衡。以 Go 语言标准库为例，压缩级别从 0 到 9 对应不同的 good、lazy、nice、chain 参数组合。级别 6 是默认值，其 nice 长度为 128，意味着找到 128 字节的匹配后就停止搜索以节省时间；级别 9 的 nice 长度为 258，即允许最长回引用，这会消耗更多 CPU 但能获得更好的压缩率。当已有匹配长度达到 good 阈值（默认 8 字节）时，搜索范围会缩小为原来的四分之一，这是一种巧妙的自适应策略：在已经找到不错匹配的情况下，不再花费过多时间寻找可能更好的结果。
高速压缩算法：Snappy 与 LZ4
当压缩速度成为首要考量时，Snappy 和 LZ4 是两个主流选择。两者都将自己定位为 LZ 系列的极速变体，在压缩率上做出适度妥协以换取数量级级的速度提升。
Snappy 最初名为 Zippy，由 Google 开发并在内部大规模使用。其设计哲学明确：压缩速度约 250 MB/s 以上，解压速度约 500 MB/s 以上，比最快模式的 zlib 快一个数量级。相应地，压缩率约为原始文本的 1.5 到 1.7 倍，HTML 的 2 到 4 倍，而 DEFLATE 可以达到 2.6 到 2.8 倍和 3 到 7 倍。
Snappy 的编码格式设计极为精巧。每个数据块由变长编码的原始长度开头，随后是若干个 chunk。每个 chunk 的首字节低两位标识类型：00 表示字面量（未压缩），01 和 10 表示回引用，11 为废弃类型。回引用的偏移量和长度通过位操作直接编码在字节中，避免了复杂的数据结构开销。
与 DEFLATE 的关键差异在于回引用搜索策略。Snappy 仅为每个哈希位置存储一个最新的回引用，而非维护完整的链表。找到第一个 4 字节匹配后就立即停止搜索，不会遍历整个哈希链。这种「满足即可」的策略是速度差异的根本原因：Snappy 牺牲了找到最优匹配的机会，但大大减少了比较次数。
LZ4 与 Snappy 非常相似，发布时间和设计目标相近。LZ4 在压缩速度和解压速度上都更胜一筹：压缩约 780 MB/s，解压约 4970 MB/s。LZ4 的独特之处在于使用 token 字段的高低 4 位分别编码字面量长度和匹配长度，每个字段最大 15，超出部分通过额外字节以 255 为增量扩展。偏移量使用 2 字节小端编码，天然将滑动窗口限制在 65535 字节。
LZ4 的一个重要优化是使用 XOR 比较来快速判断匹配长度。代码中直接将当前 8 字节与回引用位置的 8 字节进行异或操作，结果为 0 表示完全匹配。通过 TrailingZeros64 指令可以快速计算出匹配的尾随零字节数，从而一次性跳过多个字节。这种位操作友好的实现是 LZ4 能够达到极高吞吐量的关键。
LZ4 HC（High Compression）变体通过引入类似 DEFLATE 的链式哈希表，将压缩率提升至 2.721，同时保持极快的解压速度。这印证了一个核心观点：压缩算法本质上是搜索深度与压缩率的权衡。
ZSTD：现代压缩集大成者
Zstandard（ZSTD）由 Facebook（现 Meta）的 Yann Collet 于 2016 年发布，旨在同时实现高压缩率和高速度。ZSTD 的基准数据令人印象深刻：压缩率 2.887 时压缩速度可达 510 MB/s，解压速度达到 1580 MB/s。这意味着在单一算法中获得了 DEFLATE 的压缩率和 LZ4 的速度。
ZSTD 仍然基于 LZ 框架，但引入了多项高级优化。FSE（Finite State Entropy）基于非对称数字系统（ANS），是算术编码的计算高效替代品。传统算术编码需要大量乘法和除法操作，FSE 通过查表和状态转移的方式近似实现了相同的信息编码效率，同时大幅降低了计算开销。
ZSTD 的可训练字典是另一个强大特性。对于小文件或特定领域数据（如日志文件），可以先从样本数据中训练出常用模式字典。压缩时优先匹配字典中的预定义序列，这种方式能够显著提升小数据块的压缩效果，因为字典本质上是用额外的预处理开销换取了更好的局部压缩率。
工程实践参数建议
在实际项目中选择和配置压缩算法时，需要根据具体场景权衡以下因素。
数据特性是首要考虑因素。对于高重复性的文本数据，DEFLATE 和 ZSTD 能提供最佳压缩率；对于已经压缩过的数据（如 JPEG、PNG），应使用 Snappy 或 LZ4 以避免浪费 CPU；对于日志类流式数据，ZSTD 的流式压缩模式表现优异。
CPU 与带宽的相对成本决定压缩级别的选择。在 CPU 便宜而网络带宽昂贵的场景（如 CDN 边缘节点），应使用 ZSTD 级别 22 或 DEFLATE 级别 9；在 CPU 昂贵而带宽充足的场景（如实时计算任务），应使用 Snappy 或 LZ4 级别 1。
解压场景也需要纳入考量。如果解压发生在数据读取的关键路径上（如数据库查询），应优先选择解压速度更快的算法。LZ4 的解压速度约为 4 GB/s，是 DEFLATE 的十倍，在高频读取场景下总体收益可能超过压缩率的损失。
块大小参数会影响压缩效果和内存使用。较大的块（如 64KB）能提供更好的压缩率，但会增加内存占用和延迟；较小的块适合流式处理和低延迟场景。ZSTD 的默认块大小为 128KB，可根据具体场景调整。
结论
压缩算法的选择本质上是工程权衡的具体体现。DEFLATE 作为最广泛部署的算法，提供了稳定的压缩率和良好的兼容性；Snappy 和 LZ4 以极高的速度换取略低的压缩率，适合对延迟敏感的场景；ZSTD 则在两者之间取得了最佳平衡。对于大多数现代系统，ZSTD 是开始新项目的推荐选择，因为它在无需精细调参的情况下即可提供接近最优的综合表现。
参考资料
- Moncef Abboud: Taking a Look at Compression Algorithms
- RFC 1951: DEFLATE Compressed Data Format Specification
- Go 标准库 compress/flate 实现