3、日志压缩原理：压缩算法概述与性能权衡
日志压缩这件事，说白了就是用空间换时间——不对，是用CPU时间换磁盘空间。你想想看，一台生产服务器一天能产生几个GB的日志，如果不压缩，磁盘很快就撑爆了。我最早接触日志压缩时，觉得随便找个压缩工具就行，后来踩了不少坑才明白，选错压缩算法，代价可能比不压缩还大。
3.1 三种主流压缩算法：gzip / bzip2 / zstd
目前日志系统里最常见的压缩算法就这三种。我一个个说，顺便聊聊我实际用下来的感受。
gzip：老牌选手，稳定可靠
gzip 是绝大多数Linux发行版自带的压缩工具。它的压缩核心是 DEFLATE 算法，结合了LZ77和哈夫曼编码。优点很明显：速度快、兼容性好。几乎所有日志收集工具（Filebeat、Logstash、Fluentd）都原生支持gzip。
我在项目中遇到过一个问题：某次线上日志量暴增，我们临时用gzip压缩归档，结果发现压缩后的文件大小还是偏大。后来排查发现，gzip对重复模式较少的文本日志，压缩比其实一般。嗯，这里要注意，gzip适合对速度要求高、但对压缩比要求不极致的场景。
gzip -1 到 -9，-1 最快但压缩比最低，-9 最慢但压缩比最高。默认是 -6，我个人习惯用 -6 或 -7，平衡性最好。
bzip2：压缩比更高，但慢得让人着急
bzip2 用的是 Burrows-Wheeler变换（BWT） 加上游程编码和哈夫曼编码。它的压缩比通常比gzip高10%-20%，但代价是压缩和解压速度都慢不少。
我曾经在离线归档场景中尝试过bzip2——就是那种日志已经不再需要实时查询，纯粹为了长期保存。结果压缩一个10GB的文本日志，bzip2花了将近40分钟，而gzip只用了8分钟。压缩后的文件确实小了，但那个速度让我果断放弃了它作为日常方案。
zstd：后起之秀，兼顾速度与压缩比
zstd（Zstandard）是Facebook在2015年开源的压缩算法。它最大的特点是压缩级别可调范围极大，从1到22，甚至支持负级别（更快但压缩比更低）。在相同压缩比下，zstd的速度通常是gzip的2-3倍。
我现在负责的日志系统，从2020年开始全面切换到zstd。为什么？因为它在实时压缩场景下表现太出色了。举个例子，我们用zstd level 3压缩Nginx访问日志，压缩比和gzip -6差不多，但速度快了将近一倍。CPU开销也明显更低。
3.2 压缩比与性能权衡：没有银弹
你可能会问：到底选哪个算法？我的回答是：看场景。没有哪个算法在所有维度上都最优。我整理了一张对比表，方便你直观感受：
| 算法 | 压缩比（越高越好） | 压缩速度 | 解压速度 | CPU开销 | 推荐场景 |
|---|---|---|---|---|---|
| gzip | 中等（约3-5倍） | 快 | 快 | 低 | 通用场景、兼容性优先 |
| bzip2 | 较高（约4-6倍） | 慢 | 慢 | 高 | 离线归档、长期存储 |
| zstd | 高（约3-7倍，可调） | 非常快 | 非常快 | 低-中 | 实时压缩、高性能场景 |
为什么会这样？因为压缩算法的本质是用计算换空间。你想想看，算法越复杂，它就越能发现数据中的冗余模式，压缩比自然更高。但代价就是CPU时间。bzip2的BWT变换虽然强大，但计算量也大得多。
我记得有一次帮客户做日志系统选型，他们每天产生约500GB的日志。如果用gzip，压缩后约120GB；如果用zstd level 3，压缩后约110GB，而且压缩时间缩短了40%。最终我们选了zstd，因为节省的CPU资源可以用于更多的日志解析和索引。
3.3 实时压缩 vs 批量压缩
这是日志压缩里最容易踩坑的地方。我分开讲。
实时压缩：边写边压
实时压缩，就是日志在写入磁盘的同时进行压缩。典型做法是使用管道压缩，比如：
# 使用gzip实时压缩日志
tail -f /var/log/app.log | gzip -c > /var/log/app.log.gz
# 使用zstd实时压缩（推荐）
tail -f /var/log/app.log | zstd -c > /var/log/app.log.zst实时压缩的好处是磁盘占用始终可控，不会出现日志暴增撑爆磁盘的情况。但缺点也很明显：无法直接读取。你想查日志时，必须先解压。而且如果压缩进程挂了，日志可能会丢失。
批量压缩：攒够了再压
批量压缩，就是先把日志原样写入磁盘，然后定期（比如每小时、每天）启动一个压缩任务，把历史日志文件压缩归档。典型做法：
# 每小时压缩一次前一个小时的日志
0 * * * * find /var/log/app/ -name "*.log" -mmin +55 -exec gzip {} \;
# 使用zstd批量压缩，保留原始文件
0 3 * * * find /var/log/app/ -name "*.log" -mtime +1 -exec zstd --rm {} \;批量压缩的好处是对写入性能影响小，日志可以原样写入，查询也方便。但风险在于：如果日志量突然暴增，在两次压缩任务之间，磁盘可能被撑爆。
我个人习惯的做法是混合策略：
- 对高频写入的日志（比如访问日志、业务日志），使用实时压缩，用zstd level 1或2，速度优先
- 对低频或归档日志（比如错误日志、审计日志），使用批量压缩，用zstd level 5-10，压缩比优先
- 设置一个磁盘水位告警，当磁盘使用率超过80%时，自动触发紧急批量压缩
zstd --adapt 参数让zstd自动根据CPU负载调整压缩级别。CPU空闲时压得更狠，CPU忙时压得更快。这个功能在日志量波动大的场景下特别实用。
好了，关于日志压缩的原理和算法选择，我就讲这么多。下一节我们会聊到远程日志收集的传输协议和网络优化，到时候会用到今天讲的压缩知识。记住一句话：没有最好的压缩算法，只有最适合你场景的压缩策略。