主流压缩算法概览：gzip、zstd、lz4、snappy、brotli 的核心特性对比
做存储和中间件这么多年，我几乎每天都在跟压缩算法打交道。选型这件事，说白了就是一场「空间 vs 时间」的博弈。你想想看，没有一种算法能同时做到压缩比最高、速度最快、内存占用还最小——这不现实。
今天我把最常用的五种算法拉出来遛遛：gzip、zstd、lz4、snappy、brotli。它们各有各的脾气，选对了事半功倍，选错了……嗯，我曾经在一个日志系统里用错了算法，结果 CPU 直接飙到 90%，那叫一个惨。
核心结论先放这：没有银弹。LZ4 和 Snappy 追求极致速度，Zstd 和 Brotli 追求高压缩比，Gzip 则是个「老黄牛」，稳但不够快。
1. Gzip：老牌劲旅，稳如老狗
Gzip 应该是大家最熟悉的算法了。它基于 DEFLATE 算法，结合了 LZ77 和哈夫曼编码。我最早接触压缩就是用它——那时候还在做 Web 服务器优化，给静态资源开个 gzip，带宽直接省一半。
核心特性：
- 压缩比中等偏上，通常能到 3:1 到 5:1（文本数据）
- 压缩速度一般，解压速度比压缩快 2-3 倍
- 级别可调（1-9），但级别高了收益递减明显
- 几乎所有语言和平台都有原生支持
我的经验：Gzip 级别设到 6 就够了。我曾经测试过，从 6 升到 9，压缩比只提升不到 5%，但耗时翻了一倍。得不偿失。
2. Zstd：后起之秀，Facebook 出品
Zstd（Zstandard）是 Facebook 在 2015 年开源的算法。说实话，我第一次用就被它的「可伸缩性」惊到了。它支持从 -5 到 22 的压缩级别，低级别比 LZ4 还快，高级别比 Gzip 压缩比还高。
核心特性：
- 压缩比极高，级别 19+ 可接近甚至超越 Brotli
- 压缩速度可调范围极大，从「闪电快」到「极致压缩」
- 解压速度稳定，不受压缩级别影响
- 支持字典训练，对特定数据模式有奇效
重点：Zstd 的字典训练功能是我在数据库备份场景中的「秘密武器」。针对同类型数据训练一个 64KB 的字典，压缩比能再提升 20%-30%。
3. LZ4：速度之王，延迟敏感场景首选
LZ4 的设计哲学很简单——快，再快，更快。它牺牲了压缩比来换取极致的吞吐量。我在做实时日志采集系统时，毫不犹豫选了它。为什么？因为日志数据量太大，CPU 不能成为瓶颈。
核心特性：
- 压缩速度可达 500 MB/s 以上（单核）
- 解压速度更快，可达 1 GB/s 级别
- 压缩比偏低，通常只有 2:1 左右
- 内存占用极低，适合嵌入式场景
注意：LZ4 不适合做长期归档存储。我曾经在一个冷数据归档项目里试过，压缩后体积还是太大，后来换成了 Zstd 级别 19，存储成本直接降了 60%。
4. Snappy：Google 的均衡派
Snappy（原名 Zippy）是 Google 内部广泛使用的算法。它不像 LZ4 那么极端，也不像 Gzip 那么慢。说白了，它追求的是「够用就好」——压缩比凑合，速度很快，实现简单。
核心特性：
- 压缩速度接近 LZ4，解压速度略慢一点
- 压缩比比 LZ4 稍好一点点
- 不追求最高压缩比，但稳定性极好
- Google 内部大量使用：Bigtable、MapReduce、LevelDB
避坑指南：Snappy 的压缩流格式不是自描述的。我曾经在跨语言传输时踩过坑——Java 端压缩的数据，Go 端解压时因为字节序问题直接崩了。记得统一字节序和块大小。
5. Brotli：Web 场景的压缩之王
Brotli 是 Google 为 Web 场景量身定做的算法。它比 Gzip 的压缩比高 20%-30%，但压缩速度慢得多。不过，对于静态资源预压缩来说，压缩慢一点无所谓——反正是一次压缩，多次使用。
核心特性：
- 压缩比极高，文本数据可达 6:1 以上
- 压缩速度慢，尤其是级别 11 时
- 解压速度比 Gzip 略快
- 内置了对 HTML、CSS、JS 的上下文模型优化
我的建议：Brotli 只适合做「预压缩」。比如 Web 打包时把 .js、.css 提前压好，客户端请求时直接返回。别在请求时实时压缩，CPU 扛不住。
核心参数对比表
| 算法 | 压缩比 | 压缩速度 | 解压速度 | 内存占用 | 典型场景 |
|---|---|---|---|---|---|
| Gzip | 中等（3-5x） | 中等（~50 MB/s） | 较快（~150 MB/s） | 低（~256 KB） | HTTP 压缩、文件归档 |
| Zstd | 高（4-8x） | 可调（50-500 MB/s） | 快（~500 MB/s） | 中（~1 MB） | 数据库、备份、大数据 |
| LZ4 | 低（2-3x） | 极快（>500 MB/s） | 极快（>1 GB/s） | 极低（~16 KB） | 实时日志、缓存、网络 |
| Snappy | 低（2-3x） | 极快（~400 MB/s） | 快（~800 MB/s） | 低（~32 KB） | Kafka、LevelDB、大数据 |
| Brotli | 极高（5-10x） | 慢（~10 MB/s） | 较快（~200 MB/s） | 高（~8 MB） | Web 静态资源、HTTPS |
如何快速选型？
我个人的选型逻辑很简单，三步走：
- 先看延迟要求。如果延迟敏感（比如实时 API），直接选 LZ4 或 Snappy。
- 再看存储成本。如果存储是瓶颈（比如归档），选 Zstd 或 Brotli。
- 最后看生态兼容。如果团队语言杂、平台多，Gzip 和 Snappy 最稳妥。
曾经踩过的坑：我在一个跨数据中心同步项目里，一开始用了 Brotli 级别 11。结果压缩一个 100MB 的文件花了 8 秒，同步延迟直接爆炸。后来换成 Zstd 级别 3，压缩只用了 0.5 秒，压缩比只差了 10%。选型一定要结合实际场景，别盲目追求极致。