我自己第一次真正认真用Zstd是被线上日志归档逼的。那会儿服务器上一堆Nginx访问日志单天上百GB老办法是gzip压缩完扔冷存储但压缩一次要等半小时解压还原更是慢到让人怀疑人生。后来换了Zstd同一个目录压缩从半小时压到两三分钟解压基本是秒级体积还不比gzip差多少。从那次以后我给所有备份、归档、传输链路上的压缩环节都换成了Zstd期间踩了不少坑也总结出一套比较顺手的用法。这篇东西不打算写成人人都知道的命令手册就按我自己在Linux、macOS、Windows三个平台上从零用起来的全过程来写。Zstd全名Zstandard是Facebook开源的高性能压缩算法核心卖点就是“压缩速度快、解压速度极快、压缩率可调可控”。不管你是做后端开发、运维还是经常在Windows上倒腾大文件的普通用户只要碰过“压缩”这件事Zstd都值得放进工具箱。它适合处理日志、数据库导出、容器镜像、CI缓存也适合本地跨平台传文件尤其是解压那一下的体验用过就回不去。1. Zstd带来的改变以及它和gzip等工具的本质区别1.1 从一次归档踩坑说起Zstd到底解决了什么问题先讲我自己的场景。之前压缩日志一直用gzip因为它普及率高Linux上随手就有。但gzip的最大问题是压缩和解压速度都不够快尤其当数据大到GB甚至TB级别的时候CPU时间全耗在等压缩上。有一次我压缩一个12GB的数据库导出文件用gzip -6跑了大半个小时中间还因为连接断开重来了一次心态直接炸了。后来我换成Zstd同样的12GB文件默认级别直接压用了大概三分之一的时间压缩出来的体积还小一点。更让我意外的是解压速度gzip解压这个文件要五六分钟Zstd差不多一分钟内搞定。原因在于Zstd在算法设计上做了很多针对现代CPU的优化它能在压缩时预测数据里的重复模式并利用短窗口和长窗口结合的方式把常规文本、日志、JSON这类数据压缩得又快又小。对普通人来说你不需要理解LZ77、Huffman、FSE这些底层术语只要记住一个结论在绝大多数场景下Zstd的压缩率接近甚至超过gzip但压缩和解压速度却能快好几倍。如果你压缩的是重复度很高的文本、日志、导出文件这种差距会非常明显。如果是视频、图片、已压缩过的zip包那基本压不动这是所有通用压缩算法的通病不怪Zstd。1.2 和gzip、xz、7z的横向对比为什么不是越老越稳很多人一听Zstd是2016年才出来的新算法第一反应是不敢用怕兼容性不行。我刚开始也有这个顾虑但实际对比之后想法就变了。这里放一张我自己平时做选型时会看的对照表数据顺序按直观感受排工具压缩率压缩速度解压速度是否适合主流备份场景gzip一般中等中等传统可用但效率偏低bzip2略高于gzip慢很慢不推荐xz高很慢中等偏慢适合追求极致体积的离线归档7z高较慢中等跨平台支持好但命令行生态偏弱Zstd中高级别可调快极快非常合适尤其是高频压缩和解压场景这个表不是说不让你用xz如果你归档的文件需要放到长期冷存储里并且完全不在乎压缩和解压时等待的时间那xz依然是体积最优解。但只要你需要反复压缩、解压比如每天跑备份、每周清日志Zstd的优势就体现出来了。举个例子我给一个1GB的文本日志文件做过简单测试。gzip -6压缩耗时约22秒压缩后约180MBZstd -3压缩耗时约3秒压缩后约190MB体积多了5%左右Zstd -9压缩耗时约10秒压缩后约170MB已经比gzip -6小了速度还快了一倍。解压就更夸张gzip解压耗时约8秒Zstd解压只要1秒出头。这就是我敢在备份链路里全面替换gzip的原因同样的活Zstd干得更快最后的压缩结果也不吃亏。需要注意的是Zstd的压缩级别很多从1到22默认是3。级别越高压缩率越高但压缩速度越慢同时消耗的内存也更大。很多人上来就喜欢用最高级别这其实是误区后面我会单独讲怎么选级别。2. 环境准备三个平台安装与命令行快速上手2.1 Linux / macOS安装两条命令搞定在Linux上装Zstd基本没有难度各个发行版的软件源里都有。Debian和Ubuntu用apt update apt install -y zstdCentOS、Rocky、AlmaLinux这些红帽系用yum install -y zstd新版系统如果你习惯dnf直接把yum换成dnf就行。Alpine这种轻量镜像更简单apk add zstdmacOS用户用Homebrewbrew install zstd装完之后验证一下zstd --version如果能输出版本号比如*** Zstandard CLI (64-bit) v1.5.5 ***就说明环境没问题。这个步骤看着简单但我在很多服务器上见过装完就忘的情况真正要用的时候发现命令不存在所以建议装完顺手验证一下养成习惯。这里多说一句旧版Linux发行版自带的zstd版本可能比较老比如CentOS 7默认没有zstd需要先启用EPEL仓库。版本老一点不是不能用但如果对方机器上用了新版Zstd的高压缩级别或长窗口模式老版本解压时可能报“unsupported frame parameter”所以我一般建议重要备份场景下源端和目标端尽量都用较新的zstd版本。2.2 Windows下安装以及“Windows压缩工具怎么卸载”的误区Windows用户看到“压缩工具”四个字经常本能地想到系统自带的“压缩文件夹”功能然后搜出“Windows压缩工具怎么卸载”这种问题。这里必须先说清楚一个关键点Zstd和Windows自带的压缩文件夹完全两码事两者互不干扰。Windows自带的“压缩文件夹”是资源管理器里的一个shell扩展主要用来处理zip文件它是系统功能的一部分不是独立软件正常情况也没法单独卸载更没必要卸。你装了Zstd之后并不会抢它的文件关联也不会改变zip格式的处理方式。Zstd是命令行工具默认没有图形界面双击.zst文件不会像WinRAR那样弹出窗口这是正常的不是安装失败。Windows上安装Zstd最方便的方式是用包管理器。已安装Scoop的话执行scoop install zstd用Chocolatey的话choco install zstd -y不想装包管理器也可以去GitHub的facebook/zstd仓库Release页面下载Windows版本压缩包解压后把zstd.exe所在目录加到系统环境变量的Path里。加Path的步骤是右键“此电脑”-属性-高级系统设置-环境变量-编辑Path-新增一个路径然后把命令行窗口关掉重开。这里有一个我在Windows上踩过的坑下载的是别人编译的旧版zstd.exe命令行里执行没问题但解压一个由新版Zstd使用--long参数压缩的文件时报错原因就是旧版不识别长窗口帧参数。所以Windows上尽量用官方Release或包管理器里的最新版本不要图方便随便找个网盘版本。2.3 第一个压缩和解压命令30秒建立信心安装好之后先拿个小文件跑一遍完整流程。在命令行里进入一个临时目录创建一个测试文件echo hello zstd, this is a test test.txt zstd test.txt正常情况下目录里会多出一个test.txt.zst原来的test.txt还在。zstd默认不会删除源文件这跟gzip的默认行为不同gzip压缩完会把源文件删掉Zstd保留了源文件这个设计在对数据和安全感要求高的人看来更友好但如果你脚本里默认认为压缩后源文件没了就要注意区分。解压命令zstd -d test.txt.zst-d表示decompress。解压完成后目录里会重新出现test.txt或者你也可以用更直观的unzstd test.txt.zst效果一样。zstd和unzstd是两个可执行文件Windows版解压包里两个都有底层是同一个程序的不同入口。如果想压缩完直接删除源文件加上--rm参数如果不想保留压缩后的文件用--rm配合解压也可以。日常操作里我会在备份场景加上--rm因为磁盘空间本来就紧张。但测试阶段建议先不加等确认流程没问题之后再上。3. 压缩级别和关键参数怎么选才是最优解3.1 压缩级别1到22不是越高越聪明Zstd最让人困惑的就是压缩级别从1到22选项多到像在逼你选择困难症发作。我见过不少同事第一次用Zstd直接来了一句“那就最高级别吧”然后跑了半天没压完回头还嫌Zstd慢。其实级别选择这个东西完全取决于你的场景不存在一个万能答案。简单分类一下级别1到3压缩速度极快内存占用低适合日常处理、临时传输、日志压缩。默认级别3是绝大多数情况下的最优起点。级别4到9压缩率逐步提升速度仍然比gzip快一到两个量级适合备份、打包、需要长期保存的文件。级别10到15压缩率明显更好但压缩时间开始拉长适合离线归档、冷存储场景。级别16到19接近xz的压缩率耗时已经比较夸张适合一次性压缩、之后很少解压的文件。级别20到22必须配合--ultra参数才能使用压缩过程中内存占用极高如果不是为了冲击极限压缩率个人不建议在生产环境里用。我自己常用的搭配是即时压缩选zstd -3备份归档选zstd -9离线冷数据选zstd -15。19以上的级别我几乎只用过一次那个压缩比确实香但压一个10GB文件花了一个多小时过程中CPU和内存都在狂飙普通机器不一定扛得住。如果你想知道当前数据在不同级别下的表现可以用Zstd自带的基准测试命令zstd -b test.log这条命令会把默认几个级别跑一遍输出每个级别的压缩率、压缩速度和解压速度。想指定级别用-b3 -b9这种写法。不过注意基准测试会读取目标文件多次文件特别大的时候也会花不少时间适合抽样做压测不适合天天跑。3.2 影响结果的不止级别还有这些关键参数除了级别还有几个参数在实际使用中经常碰到用好了可以解决很多具体问题。第一个是--ultra。上面提过级别20到22必须显式加--ultra它允许Zstd使用超过常规限制的压缩参数。代价就是极大的内存开销和漫长的压缩时间。我的建议是永远不要在业务服务器上用除非你确认这台机器除了压缩没别的事可干。第二个是--longwindowLog。这个参数应对的是“大文件里存在长距离重复”的场景。比如几十GB的日志文件同一个堆栈信息可能隔了很远才会再次出现默认的窗口大小抓不到这种重复压缩率就会下降。加上--long27之类的参数后Zstd可以跨更大的窗口找重复压缩率会有明显提升。代价是内存占用上升而且解压端也必须支持--long否则解不开。所以它更适合归档场景不适合拿给外部合作方解压的文件。第三个是-T多线程。Zstd默认单线程压缩但对于大文件多线程能明显缩短压缩时间。用法是zstd -T0 -9 archive.tar-T0表示使用所有CPU核心。我自己的备份脚本里基本都会加-T0因为备份窗口越短越好。但要注意多线程模式会占满CPU对正在对外提供服务的机器影响很大建议在凌晨低峰期跑或者用-T4限制一下线程数。第四个是--rsyncable。这个参数对增量备份很有用它会让压缩数据每隔一段距离产生一个同步点这样rsync同步时不需要因为中间几KB变化就重传整个压缩包。代价是压缩率下降约1%左右换来的增量传输效率提升却非常明显日志类文件的远程备份场景强烈推荐。3.3 字典压缩小文件批量场景的隐藏大招Zstd有一个其他通用压缩工具很少见的功能字典压缩。简单理解就是先从一个样本集合里训练出一个“字典文件”压缩时带上这个字典对于大量结构相似的小文件比如一堆JSON日志、一堆配置文件压缩率可以大幅提升。训练字典的命令很简单zstd --train /path/to/samples/*.log -o mydict会生成一个命名为mydict的字典文件然后压缩时用-D参数指定zstd -D mydict -3 app-2024.log解压时也需要用同一个字典zstd -D mydict -d app-2024.log.zst这个功能我从去年开始用于容器日志的集中归档效果非常惊人一堆几乎相同结构的文本日志常规压缩只能压到65%左右带字典后能压到15%以下。不过字典训练有几个注意点样本必须和目标文件有相似结构样本数量越多越好至少几百个字典文件本身要妥善保存丢了字典带字典压缩的文件就废了。所以我对字典文件的备份比数据文件还上心直接扔进对象存储加版本管理。4. 实战场景备份、日志、传输与Windows使用的一次梳理4.1 数据库和目录备份管道压缩一学就会数据库导出的SQL文件是压缩需求大户。以前我的习惯是先mysqldump导出来再单独压缩中间多了一次磁盘IO还容易因为磁盘空间不够直接失败。用Zstd后我改成管道直连一条命令完成mysqldump -u root -p mydb | zstd -3 -o mydb.sql.zst这样数据库导出的数据直接进入Zstd压缩流程不落临时SQL文件省时间也省磁盘。恢复的时候更简单zstd -dc mydb.sql.zst | mysql -u root -p mydb-d是解压-c是输出到标准输出合起来-dc就是解压后直接输出给管道。这个写法在很多备份脚本里都通用建议背下来。目录备份用Zstd时要注意一点Zstd本身是单文件压缩工具不处理目录结构。想压缩整个目录得先交给tar打包。tar新版本原生支持Zstd直接写tar --zstd -cf backup.tar.zst /data如果tar版本太老不支持--zstd可以手动组合中间文件或者用管道tar -cf - /data | zstd -9 -T0 -o backup.tar.zst注意管道写法里-o后面指定的是输出文件同时因为是从标准输入读数据不能再把-当成输入文件传给zstd。目标端的环境如果没有zstd可以用tar --zstd -xf backup.tar.zst来解包或者zstd -dc backup.tar.zst | tar -xf -。我习惯在备份脚本里用后面这个管道写法因为它的兼容性更好老版本tar也不区分。4.2 日志轮转和长期归档把logrotate调教好日志轮转是Zstd最能发光发热的场景之一。原来logrotate默认用gzip我总嫌它压缩慢后来发现logrotate的配置文件里可以指定外部压缩命令直接换成zstd。拿Nginx日志举例配置写在/etc/logrotate.d/nginx里大致这样/var/log/nginx/*.log { daily rotate 30 compress compresscmd /usr/bin/zstd compressoptions -3 --rm compressext .zst missingok notifempty sharedscripts postrotate /usr/sbin/nginx -s reopen endscript }关键就三行compresscmd指定zstd路径compressoptions传参数compressext把压缩后的扩展名改成.zst。我用--rm是因为日志轮转后源文件本来就会被安排处理掉让zstd直接删源文件可以少一次文件操作。这样跑一段时间后日志目录里就是一堆.zst文件想看旧日志时执行zstd -dc 2024-12-01.access.log.zst | grep 关键字解压速度极快基本能做到“边解压边grep”体验比gzip高出一个层次。4.3 CI缓存和容器镜像提速效果立竿见影Zstd在GitHub Actions里的体现非常明显。Actions的缓存机制在较新版本里已经用上了Zstd压缩和恢复缓存的速度比之前快很多。如果你在自建的CI系统里对缓存做过压缩同样可以指定zstd -3构建机的缓存恢复时间能缩短一大截。我维护的几个项目构建缓存从1GB左右压到200MB恢复时间从半分钟降到十秒左右整个流水线体感流畅很多。容器镜像层压缩是另一个成熟的应用。Docker构建时BuildKit支持将镜像层压缩格式设成Zstd配置环境变量export BUILDKIT_COMPRESSIONzstd或在BuildKit的配置里指定compression zstd。镜像层用Zstd压缩后构建和推送速度都更快拉取解压也更快。这里唯一的坑是兼容性老版本Docker守护进程不一定支持Zstd压缩的镜像层推到仓库之后如果拉取端版本太老可能拉不下来。所以在团队内部要统一Docker版本或者至少在公共镜像上保留gzip兼容层这是我踩过坑之后学到的教训。4.4 Windows用户怎么处理GUI和文件关联问题回到Windows这个相对“非主流”的使用场景。Zstd的命令行方式在Windows的PowerShell和CMD里都能用和Linux语法完全一致。如果你实在不习惯命令行可以装PeaZip这类支持Zstd的图形压缩软件界面操作右键就能压缩解压。但需要明确一点PeaZip只是把Zstd封装成了图形界面底层的.zst文件仍然是通用的用命令行照样能解。关于Windows自带压缩工具的问题我再解释得明白一点系统自带的“压缩文件夹”不需要卸载也尽量不要去卸载或禁用。它平时不占CPU、不占内存只有在右键压缩解压zip时才会被调用。真正让Windows变卡的往往是各种第三方压缩软件的开机自启和后台驻留如果你装了WinRAR、好压、360压缩这类工具觉得烦直接卸载它们就好完全不影响Zstd的使用。卸载之后Zstd命令照常运行它依赖的是命令行环境和GUI压缩软件没有任何关系。有一种常见误解是装了Zstd之后为什么双击.zst文件没反应是不是和系统压缩工具冲突了。其实不是。Zstd官方在Windows上主打命令行没有默认的文件关联。想让.zst后缀和图形界面关联需要借助PeaZip这类工具或者在PeaZip里把.zst关联上。如果不想关联每次右键选择“打开方式”指定一下也凑合。5. 高频问题与避坑笔记照着排查基本能救回来5.1 解压报错Unrecognized file format先别急着删文件刚上手时最慌的错误就是解压时报Unrecognized file format。这个错误的意思是zstd识别不了目标文件的格式。常见原因有几种文件确实不是Zstd压缩的比如文件名被改成了.zst但内容还是gzip文件下载不完整头部数据损坏文件本身加密过或者套了一层别的格式。我的排查顺序是先用file命令看看文件真实类型file suspicious.zst如果输出显示gzip compressed data那就用gzip -dc解压。如果显示data或者ASCII text那可能文件就没压缩过直接忽略扩展名读取即可。如果显示Zstandard compressed data但zstd仍然报错那就是文件头部或中间内容损坏了这种情况只能用备份恢复或者用zstd -t做一次更详细的完整校验看错误的精确位置。5.2 压缩率达不到预期可能不是Zstd的问题有次一个同事跑完备份发现SQL文件只压了30%跑来问我怎么Zstd这么弱。我看了一下他的原始文件发现是去年已经用xz压过一遍的备份问他为什么把已压缩文件再压一遍他说为了统一归档格式。这就是典型的压缩率误区。任何通用压缩算法都只能压缩数据里的冗余已压缩过的数据冗余度极低再压一次基本白费力气还白白消耗CPU。如果你的数据确实是未压缩的文本但Zstd默认级别压出来体积不理想可以从两个方向调整一是把级别调到9到15压缩率会继续提升二是对特别大的文件试试--long参数让Zstd能在更大范围内发现重复模式。我压过一个几十GB的日志文件没用--long时压缩率大约是16%加上--long27后直接降到12%差距还是挺明显的。5.3 磁盘和内存告急级别和窗口如何妥协压缩大文件时最容易忽略的是内存问题。Zstd的解压端内存需求取决于压缩时使用的窗口大小默认一般是8MB几乎可以忽略。但如果压缩时用了--long30这类大窗口解压端也需要分配对应的大块内存在内存只有2GB的小机器上就可能卡死或OOM。推荐的做法是压缩端如果明确知道目标机器内存很小就不要用超过27的窗口如果需要超大窗口的高压缩率还要在归档说明里写清楚必须用哪个版本的zstd。我的一个无线下小服务器就吃过这个亏解压一个用--ultra -22压缩的归档文件时内存瞬间吃满最后只能拿到高配机器上解压。磁盘方面Zstd压缩和解压过程本身不产生额外临时文件不像某些工具需要临时空间存放中间结果。但管道压缩要注意输出文件和源文件不能放同一个分区且该分区剩余空间不足否则压缩到一半就把盘写满了。我的习惯是压缩前先检查目标分区剩余空间估算压缩包大小至少留出压缩前体积20%的余量。5.4 Windows场景的卸载、关联和误删问题很多Windows用户搜“压缩工具怎么卸载”其实想解决的是“我想换一个新的压缩工具”。如果你装了Zstd后觉得不好用卸载也很简单。包管理器安装的就用对应命令删除scoop uninstall zstdchoco uninstall zstd手动解压的版本更简单把整个文件夹删掉再把之前在Path里加的路径删掉就行不写注册表不留垃圾文件。Zstd对系统是“绿色软件”级别的存在这一点比很多权限混乱的国产压缩软件干净得多也是我推荐它的一部分原因。最后提醒一个容易手滑的地方删除.zst文件前一定确认解压过。我在Windows上就有过一次惨痛经历把压缩包传给客户后本地原文件删了后来发现那个压缩包因为用了带字典参数生成的文件字典没一起发过去客户解不开自己又没留份只能重新从源数据压一遍。从那以后所有带字典的压缩文件我都会在归档目录里同时保存一份字典副本并命名成:zstd-dict这样的固定后缀防止混在一起找不到。5.5 命令行找不到zstd多半是Path问题最后聊一个特别基础但很多人问的问题明明安装了Zstd但输入zstd提示command not found或者“不是内部或外部命令”。Linux和macOS上一般是安装的bin目录不在当前用户的PATH里用which zstd看一下真实的执行路径如果输出为空考虑重装或者找到安装路径后手动加入PATH。Windows上更常见的是解压了官方包但没配置环境变量。这里有个小技巧不需要非得开“系统属性”去改Path在PowerShell里临时用绝对路径调用也是一种方式D:\tools\zstd\zstd.exe --version如果你经常要用再把D:\tools\zstd加到用户Path里。加完PATH之后一定要重开终端否则当前会话不会生效这个细节能挡住一半的新手。我自己的个人体验是Zstd用顺了之后回到gzip就回不去了解压速度和压缩速度的优势实在太明显。如果你正好在纠结备份脚本、日志轮转、大文件传输这些场景拿个小文件先试一把Zstd应该能很快感受到区别。最后再分享一个小技巧所有用到管道压缩的地方无论是tar、mysqldump还是rsync都值得先跑一遍小数据量测试再上生产因为不同版本的Zstd在某些参数组合下的表现差异还是存在的提前测一遍能省掉很多麻烦。
Zstd压缩算法实战指南：比gzip更快的高效压缩工具
我自己第一次真正认真用Zstd是被线上日志归档逼的。那会儿服务器上一堆Nginx访问日志单天上百GB老办法是gzip压缩完扔冷存储但压缩一次要等半小时解压还原更是慢到让人怀疑人生。后来换了Zstd同一个目录压缩从半小时压到两三分钟解压基本是秒级体积还不比gzip差多少。从那次以后我给所有备份、归档、传输链路上的压缩环节都换成了Zstd期间踩了不少坑也总结出一套比较顺手的用法。这篇东西不打算写成人人都知道的命令手册就按我自己在Linux、macOS、Windows三个平台上从零用起来的全过程来写。Zstd全名Zstandard是Facebook开源的高性能压缩算法核心卖点就是“压缩速度快、解压速度极快、压缩率可调可控”。不管你是做后端开发、运维还是经常在Windows上倒腾大文件的普通用户只要碰过“压缩”这件事Zstd都值得放进工具箱。它适合处理日志、数据库导出、容器镜像、CI缓存也适合本地跨平台传文件尤其是解压那一下的体验用过就回不去。1. Zstd带来的改变以及它和gzip等工具的本质区别1.1 从一次归档踩坑说起Zstd到底解决了什么问题先讲我自己的场景。之前压缩日志一直用gzip因为它普及率高Linux上随手就有。但gzip的最大问题是压缩和解压速度都不够快尤其当数据大到GB甚至TB级别的时候CPU时间全耗在等压缩上。有一次我压缩一个12GB的数据库导出文件用gzip -6跑了大半个小时中间还因为连接断开重来了一次心态直接炸了。后来我换成Zstd同样的12GB文件默认级别直接压用了大概三分之一的时间压缩出来的体积还小一点。更让我意外的是解压速度gzip解压这个文件要五六分钟Zstd差不多一分钟内搞定。原因在于Zstd在算法设计上做了很多针对现代CPU的优化它能在压缩时预测数据里的重复模式并利用短窗口和长窗口结合的方式把常规文本、日志、JSON这类数据压缩得又快又小。对普通人来说你不需要理解LZ77、Huffman、FSE这些底层术语只要记住一个结论在绝大多数场景下Zstd的压缩率接近甚至超过gzip但压缩和解压速度却能快好几倍。如果你压缩的是重复度很高的文本、日志、导出文件这种差距会非常明显。如果是视频、图片、已压缩过的zip包那基本压不动这是所有通用压缩算法的通病不怪Zstd。1.2 和gzip、xz、7z的横向对比为什么不是越老越稳很多人一听Zstd是2016年才出来的新算法第一反应是不敢用怕兼容性不行。我刚开始也有这个顾虑但实际对比之后想法就变了。这里放一张我自己平时做选型时会看的对照表数据顺序按直观感受排工具压缩率压缩速度解压速度是否适合主流备份场景gzip一般中等中等传统可用但效率偏低bzip2略高于gzip慢很慢不推荐xz高很慢中等偏慢适合追求极致体积的离线归档7z高较慢中等跨平台支持好但命令行生态偏弱Zstd中高级别可调快极快非常合适尤其是高频压缩和解压场景这个表不是说不让你用xz如果你归档的文件需要放到长期冷存储里并且完全不在乎压缩和解压时等待的时间那xz依然是体积最优解。但只要你需要反复压缩、解压比如每天跑备份、每周清日志Zstd的优势就体现出来了。举个例子我给一个1GB的文本日志文件做过简单测试。gzip -6压缩耗时约22秒压缩后约180MBZstd -3压缩耗时约3秒压缩后约190MB体积多了5%左右Zstd -9压缩耗时约10秒压缩后约170MB已经比gzip -6小了速度还快了一倍。解压就更夸张gzip解压耗时约8秒Zstd解压只要1秒出头。这就是我敢在备份链路里全面替换gzip的原因同样的活Zstd干得更快最后的压缩结果也不吃亏。需要注意的是Zstd的压缩级别很多从1到22默认是3。级别越高压缩率越高但压缩速度越慢同时消耗的内存也更大。很多人上来就喜欢用最高级别这其实是误区后面我会单独讲怎么选级别。2. 环境准备三个平台安装与命令行快速上手2.1 Linux / macOS安装两条命令搞定在Linux上装Zstd基本没有难度各个发行版的软件源里都有。Debian和Ubuntu用apt update apt install -y zstdCentOS、Rocky、AlmaLinux这些红帽系用yum install -y zstd新版系统如果你习惯dnf直接把yum换成dnf就行。Alpine这种轻量镜像更简单apk add zstdmacOS用户用Homebrewbrew install zstd装完之后验证一下zstd --version如果能输出版本号比如*** Zstandard CLI (64-bit) v1.5.5 ***就说明环境没问题。这个步骤看着简单但我在很多服务器上见过装完就忘的情况真正要用的时候发现命令不存在所以建议装完顺手验证一下养成习惯。这里多说一句旧版Linux发行版自带的zstd版本可能比较老比如CentOS 7默认没有zstd需要先启用EPEL仓库。版本老一点不是不能用但如果对方机器上用了新版Zstd的高压缩级别或长窗口模式老版本解压时可能报“unsupported frame parameter”所以我一般建议重要备份场景下源端和目标端尽量都用较新的zstd版本。2.2 Windows下安装以及“Windows压缩工具怎么卸载”的误区Windows用户看到“压缩工具”四个字经常本能地想到系统自带的“压缩文件夹”功能然后搜出“Windows压缩工具怎么卸载”这种问题。这里必须先说清楚一个关键点Zstd和Windows自带的压缩文件夹完全两码事两者互不干扰。Windows自带的“压缩文件夹”是资源管理器里的一个shell扩展主要用来处理zip文件它是系统功能的一部分不是独立软件正常情况也没法单独卸载更没必要卸。你装了Zstd之后并不会抢它的文件关联也不会改变zip格式的处理方式。Zstd是命令行工具默认没有图形界面双击.zst文件不会像WinRAR那样弹出窗口这是正常的不是安装失败。Windows上安装Zstd最方便的方式是用包管理器。已安装Scoop的话执行scoop install zstd用Chocolatey的话choco install zstd -y不想装包管理器也可以去GitHub的facebook/zstd仓库Release页面下载Windows版本压缩包解压后把zstd.exe所在目录加到系统环境变量的Path里。加Path的步骤是右键“此电脑”-属性-高级系统设置-环境变量-编辑Path-新增一个路径然后把命令行窗口关掉重开。这里有一个我在Windows上踩过的坑下载的是别人编译的旧版zstd.exe命令行里执行没问题但解压一个由新版Zstd使用--long参数压缩的文件时报错原因就是旧版不识别长窗口帧参数。所以Windows上尽量用官方Release或包管理器里的最新版本不要图方便随便找个网盘版本。2.3 第一个压缩和解压命令30秒建立信心安装好之后先拿个小文件跑一遍完整流程。在命令行里进入一个临时目录创建一个测试文件echo hello zstd, this is a test test.txt zstd test.txt正常情况下目录里会多出一个test.txt.zst原来的test.txt还在。zstd默认不会删除源文件这跟gzip的默认行为不同gzip压缩完会把源文件删掉Zstd保留了源文件这个设计在对数据和安全感要求高的人看来更友好但如果你脚本里默认认为压缩后源文件没了就要注意区分。解压命令zstd -d test.txt.zst-d表示decompress。解压完成后目录里会重新出现test.txt或者你也可以用更直观的unzstd test.txt.zst效果一样。zstd和unzstd是两个可执行文件Windows版解压包里两个都有底层是同一个程序的不同入口。如果想压缩完直接删除源文件加上--rm参数如果不想保留压缩后的文件用--rm配合解压也可以。日常操作里我会在备份场景加上--rm因为磁盘空间本来就紧张。但测试阶段建议先不加等确认流程没问题之后再上。3. 压缩级别和关键参数怎么选才是最优解3.1 压缩级别1到22不是越高越聪明Zstd最让人困惑的就是压缩级别从1到22选项多到像在逼你选择困难症发作。我见过不少同事第一次用Zstd直接来了一句“那就最高级别吧”然后跑了半天没压完回头还嫌Zstd慢。其实级别选择这个东西完全取决于你的场景不存在一个万能答案。简单分类一下级别1到3压缩速度极快内存占用低适合日常处理、临时传输、日志压缩。默认级别3是绝大多数情况下的最优起点。级别4到9压缩率逐步提升速度仍然比gzip快一到两个量级适合备份、打包、需要长期保存的文件。级别10到15压缩率明显更好但压缩时间开始拉长适合离线归档、冷存储场景。级别16到19接近xz的压缩率耗时已经比较夸张适合一次性压缩、之后很少解压的文件。级别20到22必须配合--ultra参数才能使用压缩过程中内存占用极高如果不是为了冲击极限压缩率个人不建议在生产环境里用。我自己常用的搭配是即时压缩选zstd -3备份归档选zstd -9离线冷数据选zstd -15。19以上的级别我几乎只用过一次那个压缩比确实香但压一个10GB文件花了一个多小时过程中CPU和内存都在狂飙普通机器不一定扛得住。如果你想知道当前数据在不同级别下的表现可以用Zstd自带的基准测试命令zstd -b test.log这条命令会把默认几个级别跑一遍输出每个级别的压缩率、压缩速度和解压速度。想指定级别用-b3 -b9这种写法。不过注意基准测试会读取目标文件多次文件特别大的时候也会花不少时间适合抽样做压测不适合天天跑。3.2 影响结果的不止级别还有这些关键参数除了级别还有几个参数在实际使用中经常碰到用好了可以解决很多具体问题。第一个是--ultra。上面提过级别20到22必须显式加--ultra它允许Zstd使用超过常规限制的压缩参数。代价就是极大的内存开销和漫长的压缩时间。我的建议是永远不要在业务服务器上用除非你确认这台机器除了压缩没别的事可干。第二个是--longwindowLog。这个参数应对的是“大文件里存在长距离重复”的场景。比如几十GB的日志文件同一个堆栈信息可能隔了很远才会再次出现默认的窗口大小抓不到这种重复压缩率就会下降。加上--long27之类的参数后Zstd可以跨更大的窗口找重复压缩率会有明显提升。代价是内存占用上升而且解压端也必须支持--long否则解不开。所以它更适合归档场景不适合拿给外部合作方解压的文件。第三个是-T多线程。Zstd默认单线程压缩但对于大文件多线程能明显缩短压缩时间。用法是zstd -T0 -9 archive.tar-T0表示使用所有CPU核心。我自己的备份脚本里基本都会加-T0因为备份窗口越短越好。但要注意多线程模式会占满CPU对正在对外提供服务的机器影响很大建议在凌晨低峰期跑或者用-T4限制一下线程数。第四个是--rsyncable。这个参数对增量备份很有用它会让压缩数据每隔一段距离产生一个同步点这样rsync同步时不需要因为中间几KB变化就重传整个压缩包。代价是压缩率下降约1%左右换来的增量传输效率提升却非常明显日志类文件的远程备份场景强烈推荐。3.3 字典压缩小文件批量场景的隐藏大招Zstd有一个其他通用压缩工具很少见的功能字典压缩。简单理解就是先从一个样本集合里训练出一个“字典文件”压缩时带上这个字典对于大量结构相似的小文件比如一堆JSON日志、一堆配置文件压缩率可以大幅提升。训练字典的命令很简单zstd --train /path/to/samples/*.log -o mydict会生成一个命名为mydict的字典文件然后压缩时用-D参数指定zstd -D mydict -3 app-2024.log解压时也需要用同一个字典zstd -D mydict -d app-2024.log.zst这个功能我从去年开始用于容器日志的集中归档效果非常惊人一堆几乎相同结构的文本日志常规压缩只能压到65%左右带字典后能压到15%以下。不过字典训练有几个注意点样本必须和目标文件有相似结构样本数量越多越好至少几百个字典文件本身要妥善保存丢了字典带字典压缩的文件就废了。所以我对字典文件的备份比数据文件还上心直接扔进对象存储加版本管理。4. 实战场景备份、日志、传输与Windows使用的一次梳理4.1 数据库和目录备份管道压缩一学就会数据库导出的SQL文件是压缩需求大户。以前我的习惯是先mysqldump导出来再单独压缩中间多了一次磁盘IO还容易因为磁盘空间不够直接失败。用Zstd后我改成管道直连一条命令完成mysqldump -u root -p mydb | zstd -3 -o mydb.sql.zst这样数据库导出的数据直接进入Zstd压缩流程不落临时SQL文件省时间也省磁盘。恢复的时候更简单zstd -dc mydb.sql.zst | mysql -u root -p mydb-d是解压-c是输出到标准输出合起来-dc就是解压后直接输出给管道。这个写法在很多备份脚本里都通用建议背下来。目录备份用Zstd时要注意一点Zstd本身是单文件压缩工具不处理目录结构。想压缩整个目录得先交给tar打包。tar新版本原生支持Zstd直接写tar --zstd -cf backup.tar.zst /data如果tar版本太老不支持--zstd可以手动组合中间文件或者用管道tar -cf - /data | zstd -9 -T0 -o backup.tar.zst注意管道写法里-o后面指定的是输出文件同时因为是从标准输入读数据不能再把-当成输入文件传给zstd。目标端的环境如果没有zstd可以用tar --zstd -xf backup.tar.zst来解包或者zstd -dc backup.tar.zst | tar -xf -。我习惯在备份脚本里用后面这个管道写法因为它的兼容性更好老版本tar也不区分。4.2 日志轮转和长期归档把logrotate调教好日志轮转是Zstd最能发光发热的场景之一。原来logrotate默认用gzip我总嫌它压缩慢后来发现logrotate的配置文件里可以指定外部压缩命令直接换成zstd。拿Nginx日志举例配置写在/etc/logrotate.d/nginx里大致这样/var/log/nginx/*.log { daily rotate 30 compress compresscmd /usr/bin/zstd compressoptions -3 --rm compressext .zst missingok notifempty sharedscripts postrotate /usr/sbin/nginx -s reopen endscript }关键就三行compresscmd指定zstd路径compressoptions传参数compressext把压缩后的扩展名改成.zst。我用--rm是因为日志轮转后源文件本来就会被安排处理掉让zstd直接删源文件可以少一次文件操作。这样跑一段时间后日志目录里就是一堆.zst文件想看旧日志时执行zstd -dc 2024-12-01.access.log.zst | grep 关键字解压速度极快基本能做到“边解压边grep”体验比gzip高出一个层次。4.3 CI缓存和容器镜像提速效果立竿见影Zstd在GitHub Actions里的体现非常明显。Actions的缓存机制在较新版本里已经用上了Zstd压缩和恢复缓存的速度比之前快很多。如果你在自建的CI系统里对缓存做过压缩同样可以指定zstd -3构建机的缓存恢复时间能缩短一大截。我维护的几个项目构建缓存从1GB左右压到200MB恢复时间从半分钟降到十秒左右整个流水线体感流畅很多。容器镜像层压缩是另一个成熟的应用。Docker构建时BuildKit支持将镜像层压缩格式设成Zstd配置环境变量export BUILDKIT_COMPRESSIONzstd或在BuildKit的配置里指定compression zstd。镜像层用Zstd压缩后构建和推送速度都更快拉取解压也更快。这里唯一的坑是兼容性老版本Docker守护进程不一定支持Zstd压缩的镜像层推到仓库之后如果拉取端版本太老可能拉不下来。所以在团队内部要统一Docker版本或者至少在公共镜像上保留gzip兼容层这是我踩过坑之后学到的教训。4.4 Windows用户怎么处理GUI和文件关联问题回到Windows这个相对“非主流”的使用场景。Zstd的命令行方式在Windows的PowerShell和CMD里都能用和Linux语法完全一致。如果你实在不习惯命令行可以装PeaZip这类支持Zstd的图形压缩软件界面操作右键就能压缩解压。但需要明确一点PeaZip只是把Zstd封装成了图形界面底层的.zst文件仍然是通用的用命令行照样能解。关于Windows自带压缩工具的问题我再解释得明白一点系统自带的“压缩文件夹”不需要卸载也尽量不要去卸载或禁用。它平时不占CPU、不占内存只有在右键压缩解压zip时才会被调用。真正让Windows变卡的往往是各种第三方压缩软件的开机自启和后台驻留如果你装了WinRAR、好压、360压缩这类工具觉得烦直接卸载它们就好完全不影响Zstd的使用。卸载之后Zstd命令照常运行它依赖的是命令行环境和GUI压缩软件没有任何关系。有一种常见误解是装了Zstd之后为什么双击.zst文件没反应是不是和系统压缩工具冲突了。其实不是。Zstd官方在Windows上主打命令行没有默认的文件关联。想让.zst后缀和图形界面关联需要借助PeaZip这类工具或者在PeaZip里把.zst关联上。如果不想关联每次右键选择“打开方式”指定一下也凑合。5. 高频问题与避坑笔记照着排查基本能救回来5.1 解压报错Unrecognized file format先别急着删文件刚上手时最慌的错误就是解压时报Unrecognized file format。这个错误的意思是zstd识别不了目标文件的格式。常见原因有几种文件确实不是Zstd压缩的比如文件名被改成了.zst但内容还是gzip文件下载不完整头部数据损坏文件本身加密过或者套了一层别的格式。我的排查顺序是先用file命令看看文件真实类型file suspicious.zst如果输出显示gzip compressed data那就用gzip -dc解压。如果显示data或者ASCII text那可能文件就没压缩过直接忽略扩展名读取即可。如果显示Zstandard compressed data但zstd仍然报错那就是文件头部或中间内容损坏了这种情况只能用备份恢复或者用zstd -t做一次更详细的完整校验看错误的精确位置。5.2 压缩率达不到预期可能不是Zstd的问题有次一个同事跑完备份发现SQL文件只压了30%跑来问我怎么Zstd这么弱。我看了一下他的原始文件发现是去年已经用xz压过一遍的备份问他为什么把已压缩文件再压一遍他说为了统一归档格式。这就是典型的压缩率误区。任何通用压缩算法都只能压缩数据里的冗余已压缩过的数据冗余度极低再压一次基本白费力气还白白消耗CPU。如果你的数据确实是未压缩的文本但Zstd默认级别压出来体积不理想可以从两个方向调整一是把级别调到9到15压缩率会继续提升二是对特别大的文件试试--long参数让Zstd能在更大范围内发现重复模式。我压过一个几十GB的日志文件没用--long时压缩率大约是16%加上--long27后直接降到12%差距还是挺明显的。5.3 磁盘和内存告急级别和窗口如何妥协压缩大文件时最容易忽略的是内存问题。Zstd的解压端内存需求取决于压缩时使用的窗口大小默认一般是8MB几乎可以忽略。但如果压缩时用了--long30这类大窗口解压端也需要分配对应的大块内存在内存只有2GB的小机器上就可能卡死或OOM。推荐的做法是压缩端如果明确知道目标机器内存很小就不要用超过27的窗口如果需要超大窗口的高压缩率还要在归档说明里写清楚必须用哪个版本的zstd。我的一个无线下小服务器就吃过这个亏解压一个用--ultra -22压缩的归档文件时内存瞬间吃满最后只能拿到高配机器上解压。磁盘方面Zstd压缩和解压过程本身不产生额外临时文件不像某些工具需要临时空间存放中间结果。但管道压缩要注意输出文件和源文件不能放同一个分区且该分区剩余空间不足否则压缩到一半就把盘写满了。我的习惯是压缩前先检查目标分区剩余空间估算压缩包大小至少留出压缩前体积20%的余量。5.4 Windows场景的卸载、关联和误删问题很多Windows用户搜“压缩工具怎么卸载”其实想解决的是“我想换一个新的压缩工具”。如果你装了Zstd后觉得不好用卸载也很简单。包管理器安装的就用对应命令删除scoop uninstall zstdchoco uninstall zstd手动解压的版本更简单把整个文件夹删掉再把之前在Path里加的路径删掉就行不写注册表不留垃圾文件。Zstd对系统是“绿色软件”级别的存在这一点比很多权限混乱的国产压缩软件干净得多也是我推荐它的一部分原因。最后提醒一个容易手滑的地方删除.zst文件前一定确认解压过。我在Windows上就有过一次惨痛经历把压缩包传给客户后本地原文件删了后来发现那个压缩包因为用了带字典参数生成的文件字典没一起发过去客户解不开自己又没留份只能重新从源数据压一遍。从那以后所有带字典的压缩文件我都会在归档目录里同时保存一份字典副本并命名成:zstd-dict这样的固定后缀防止混在一起找不到。5.5 命令行找不到zstd多半是Path问题最后聊一个特别基础但很多人问的问题明明安装了Zstd但输入zstd提示command not found或者“不是内部或外部命令”。Linux和macOS上一般是安装的bin目录不在当前用户的PATH里用which zstd看一下真实的执行路径如果输出为空考虑重装或者找到安装路径后手动加入PATH。Windows上更常见的是解压了官方包但没配置环境变量。这里有个小技巧不需要非得开“系统属性”去改Path在PowerShell里临时用绝对路径调用也是一种方式D:\tools\zstd\zstd.exe --version如果你经常要用再把D:\tools\zstd加到用户Path里。加完PATH之后一定要重开终端否则当前会话不会生效这个细节能挡住一半的新手。我自己的个人体验是Zstd用顺了之后回到gzip就回不去了解压速度和压缩速度的优势实在太明显。如果你正好在纠结备份脚本、日志轮转、大文件传输这些场景拿个小文件先试一把Zstd应该能很快感受到区别。最后再分享一个小技巧所有用到管道压缩的地方无论是tar、mysqldump还是rsync都值得先跑一遍小数据量测试再上生产因为不同版本的Zstd在某些参数组合下的表现差异还是存在的提前测一遍能省掉很多麻烦。
