日志压缩概述

日志这东西，每个系统都在疯狂地写。我见过一个微服务集群，单日日志量轻松超过 100GB。不压缩？磁盘扛不住，网络也扛不住。说白了，日志压缩就是给数据“减减肥”，让它们占更少地方、花更少带宽。

为什么需要压缩日志

先聊聊硬成本。一台服务器，1TB 的 SSD 多少钱？日志存 7 天还是 30 天，成本差好几倍。我个人习惯把日志保留策略和压缩方案放在一起设计，效果最直接。

• 存储成本：压缩比 10:1 意味着同样磁盘可以存 10 倍量的原始日志。我曾在项目里把 8TB 的归档日志压到 800GB，省下的那点钱够买两台新服务器。
• 传输带宽：日志要跨机房、跨云同步？压缩后的数据流量只有原来的 1/5 到 1/10，延迟也降了。
• I/O 性能：写日志时系统卡住，很大程度是磁盘 I/O 满了。压缩后写入量减少，系统响应明显变快。嗯，这里要注意——压缩本身需要 CPU，但现代 CPU 处理这点压缩绰绰有余。
• 合规与审计：很多行业要求日志保留 1 年甚至更久。不压缩，光电费就够喝一壶。

日志压缩的挑战

说实话，压缩日志不是无脑上 gzip 就完事了。我踩过不少坑，总结起来大概这几类：

挑战	具体表现	我曾经踩过的坑
实时性	日志产生速度极快，压缩不能拖慢写入	有一次用 snappy 压实时流，CPU 被占满，日志写入延迟飙到秒级……后来换了 lz4 才稳住。
数据完整性	压缩和解压不能丢行、不能乱序	早期用自定义压缩库，解压后有几行乱码，排查了三天才发现是流式边界处理的问题。
压缩率 vs 速度	高压缩率往往意味着慢，快压缩往往体积大	归档日志用 zstd 慢一点无所谓，但实时日志必须选快的，比如 lz4 或 snappy。
资源消耗	压缩吃 CPU，解压也吃 CPU	我习惯在低峰期做批量归档压缩，实时压缩只用硬件辅助或轻量算法。
版本兼容	压缩算法版本升级可能导致老数据无法解压	记得有一次同事升级了库，旧日志全废了……从那以后我坚持在压缩文件头里写算法版本号。

基本目标

讲清楚挑战，目标就很明确了。我把它概括为四个维度：

1. 高压缩比——尽量少占磁盘，尤其是冷数据归档场景。
2. 低延迟——特别是实时写入阶段，压缩延迟不能超过日志生成间隔。
3. 低 CPU 开销——不能为了省磁盘把 CPU 打满，导致业务服务降级。
4. 可解压 & 可兼容——任何时候都能正确还原，支持版本演进。

不同场景侧重点不一样。例如：

• 实时日志流水：优先低 CPU、低延迟，压缩比可以妥协。LZ4 是这类的代表。
• 归档备份：优先高压缩比，允许花更多时间压缩。gzip、bzip2、zstd（高等级）都合适。
• 跨网络传输：平衡压缩比和压缩速度，zstd 在中等级别表现很好。

你看，整个流程并不复杂。选对算法、分场景处理，日志压缩就能帮你省下真金白银和运维精力。我现在的习惯是：实时写入用 LZ4，归档批处理用 zstd（等级 5~10），跨机房传输用 zstd（等级 3）。三套方案配合，既稳又省。