Golang并行压缩库Pzip原理解析

pzip不兼容标准gzip因采用分块并行压缩：每块独立gzip压缩，仅保留首块header和末块trailer，中间块用NoHeader模式，需专用解压器。

为什么 pzip 不是简单起见用 gzip + runtime.GOMAXPROCS

因为标准 gzip.Writer 内部状态（比如哈夫曼树、滑动窗口）不是并发安全的，强行多 goroutine 写同一个 gzip.Writer 会 panic 或产生损坏数据。而 pzip 的核心思路是「分块并行压缩 + 后续拼接」，不是让多个 goroutine 并发写同一压缩流。

它把输入数据切分成固定大小块（默认 1MB），每个块独立调用 gzip.NewWriter 压缩，再把各块压缩结果按顺序拼起来——但这样直接拼出来的字节流不符合 gzip 格式规范（缺少全局 header/trailer，且各块 trailer 会干扰下一个块）。

• 真正实现时，pzip 会丢弃中间块的 gzip trailer（即最后 8 字节），只保留第一个块的 header 和最后一个块的 trailer
• 每个中间块实际用的是 gzip.NoHeader 模式，避免重复 header；解压端需配合识别这种“multi-block without inter-block headers”格式
• 这意味着：它不是标准 gzip 兼容的，不能直接用 gunzip 解，必须用配套的 pzip 解压器或手动处理块边界

pzip 的压缩块大小怎么选？默认 1MB 合理吗

块太小（如 64KB）：线程调度和内存分配开销占比上升，压缩率下降（小块难以建立有效字典）；块太大（如 16MB）：单块压缩耗时拉长，无法充分利用 CPU 核心，且内存峰值飙升（每块需独立缓冲区）。

实测在多数 SSD+16 核场景下，512KB–2MB 是较优区间。关键看你的数据局部重复性：

• 日志类（高重复前缀）：可尝试 256KB，更快收敛字典
• JSON/文本混合（中等重复）：1MB 是平衡点
• 已加密或随机二进制数据：别用 pzip，压缩率接近 0，还白占 CPU

设置方式是传入 pzip.Options{BlockSize: 1024 * 1024}，不是改环境变量或全局配置。

为什么用 pzip 压缩后文件反而变大了

这不是 bug，是分块压缩固有代价：每个块都要携带自己的 gzip header（10 字节）和（除最后一块外）被丢弃的 trailer；更严重的是，小块无法复用跨块的字典信息，LZ77 匹配距离受限。

典型表现：

• 原始文件 < 1MB：基本没收益，甚至膨胀 2%–5%
• 含大量短重复串（如 {"id":1,"name":"a"} 连续出现）：单块内匹配不到跨块重复，压缩率比单线程 gzip 低 10%+
• 用了 gzip.BestSpeed 级别：块内压缩本就粗糙，叠加分块损失，效果更差

建议先用 head -c 10M bigfile | gzip | wc -c 和 pzip -b 1M | wc -c 对比 10MB 样本，别直接压全量。

如何判断当前数据是否适合 pzip

适合的核心信号只有一个：文件足够大（≥50MB）且内容有中长距离重复模式（比如数据库 dump、归档日志、CSV 表格）。其他都是次要条件。

快速验证步骤：

• 用 gztool -v file.gz 查看单线程 gzip 的压缩比和平均匹配长度（avg match len > 20 更可能受益）
• 跑一次 pzip -b 1M -o test.pz file，再用 gunzip -t test.pz —— 会失败，说明你忘了它不兼容标准工具；正确验算应是 pzip -d test.pz | sha256sum 对比原文件
• 监控 top -p $(pgrep -f "pzip")，如果 CPU 利用率长期卡在 100% ×（逻辑核数 − 1），说明 I/O 或锁瓶颈，不是计算瓶颈，这时加核无用

真正难处理的是半结构化数据：比如 protobuf 序列化后的二进制流，重复模式隐含在字段偏移中，pzip 这种基于字节流的分块完全抓不住——这种场景得换 zstd 多线程模式或自定义分帧逻辑。