title: Zstd 級(jí)別拉到 19 那天采集 agent 把自己壓死了LZ4、Snappy、Zstd 的 4 個(gè)真實(shí)賬topic: 壓縮算法對(duì)比LZ4、Snappy、Zstdbatch: 6round: 3我們?nèi)罩静杉?agent 早期直接把原始 JSON 往 Kafka 丟帶寬一個(gè)月燒掉 6 萬。有人提議「上 Zstd壓縮比高」我腦子一熱把壓縮級(jí)別設(shè)成 19Zstd 最高檔附近心想壓縮比越高越省帶寬。結(jié)果 agent 部署后 CPU 從 15% 飆到 100%把所在機(jī)器的其他進(jìn)程全拖慢Kafka 沒省多少帶寬卻差點(diǎn)把采集節(jié)點(diǎn)搞崩。壓縮不是「級(jí)別越高越好」它本質(zhì)是 CPU 和帶寬的置換級(jí)別調(diào)錯(cuò)就是拿 CPU 換那幾個(gè)百分點(diǎn)的壓縮比。這篇文章用我們交的學(xué)費(fèi)把 LZ4、Snappy、Zstd 三個(gè)常選算法的真實(shí)賬算清楚。事故Zstd 級(jí)別 19CPU 換來了多少帶寬我當(dāng)時(shí)的代碼簡(jiǎn)化public class LogCompressor { private final ZstdCompressor compressor new ZstdCompressor(); public byte[] compress(byte[] raw) { // level 19追求極致壓縮比 int level 19; return compressor.compress(raw, level); } }逐行解釋為什么這版是坑- 第 4 行new ZstdCompressor()用的是zstd-jniFacebook 的 JNI 封裝它調(diào)用原生 Zstd 庫級(jí)別越高壓縮時(shí)搜索匹配串的窗口越大、嘗試越深。- 第 6 行l(wèi)evel 19是接近最高的級(jí)別。我們一條日志平均 800 字節(jié)級(jí)別從 3 提到 19壓縮比只從 3.4 提到 3.9但單條壓縮耗時(shí)從 8 微秒漲到 210 微秒漲了 26 倍。- 采集 agent 單機(jī)每秒要壓 4 萬條日志級(jí)別 19 時(shí)壓縮線程直接 100% 滿載連帶 GC 也漲壓縮中間 buffer 多機(jī)器 load 從 2 飆到 20同機(jī)上的訂單上報(bào)服務(wù) P99 都受了影響。修正級(jí)別降到 3壓縮比幾乎沒掉CPU 砍回去了public class LogCompressor { private static final int LEVEL 3; // 性價(jià)比甜區(qū)不是越高越好 public byte[] compress(byte[] raw) { return Zstd.compress(raw, LEVEL); // 靜態(tài)方法避免重復(fù) new } public byte[] decompress(byte[] in, int originalLen) { return Zstd.decompress(in, originalLen); // 解壓必須知道原始長(zhǎng)度 } }逐行解釋- 第 2 行LEVEL 3是 Zstd 的「快速檔」。實(shí)測(cè)級(jí)別 1~3 壓縮比只比 19 低一點(diǎn)點(diǎn)3.4 vs 3.9但 CPU 只有 19 級(jí)的零頭。我們把級(jí)別定在 3帶寬省了和 19 級(jí)差不多的量CPU 回到 18%。- 第 6 行Zstd.decompress(in, originalLen)提醒一個(gè)坑Zstd 解壓需要你提供原始長(zhǎng)度或幀里有記錄我們第一次解壓忘了傳長(zhǎng)度默認(rèn)按 0 處理直接報(bào)錯(cuò)。壓縮框架幾乎都要求「壓縮時(shí)記住原始長(zhǎng)度」寫工具類時(shí)務(wù)必一起存。- 第 2 行「靜態(tài)方法」是我們踩過的另一個(gè)坑new ZstdCompressor()每次 new 在高頻調(diào)用下對(duì)象創(chuàng)建開銷也不小直接用Zstd.compress靜態(tài)方法省掉對(duì)象。三個(gè)算法的真實(shí)定位一張對(duì)比表光講 Zstd 不夠我們把三個(gè)常用算法在日志場(chǎng)景壓了一組數(shù)算法壓縮比日志壓縮速度解壓速度適合的場(chǎng)景LZ42.1極快極快追求低延遲、CPU 敏感壓縮比要求不高Snappy2.4很快很快和 LZ4 同類Google 系生態(tài)默認(rèn)Hadoop/ESZstd (lvl 1-3)3.3快極快要兼顧壓縮比和速度帶寬貴時(shí)首選Zstd (lvl 19)3.9極慢極快離線歸檔、冷數(shù)據(jù)CPU 不敏感我的取舍線上傳輸/采集這種「CPU 和帶寬都敏感、且實(shí)時(shí)」的場(chǎng)景Zstd 級(jí)別 1~3 或 LZ4 最穩(wěn)Snappy 是「生態(tài)默認(rèn)」選比如你們已經(jīng)在用 Hadoop/Elasticsearch 的管道單獨(dú)引入沒優(yōu)勢(shì)。Zstd 19 級(jí)只留給「一次寫入、多次讀、幾乎不壓縮」的離線歸檔比如我們的歷史日志冷存壓縮一次 CPU 燒了無所謂省下的對(duì)象存儲(chǔ)費(fèi)用是真金白銀。第二個(gè)坑小數(shù)據(jù)壓縮反而膨脹我們還有個(gè)場(chǎng)景把每條 MQ 消息體平均 200 字節(jié)單獨(dú)壓縮后發(fā)送。上線后一看帶寬沒降反升排查發(fā)現(xiàn)是「小數(shù)據(jù)壓縮膨脹」。public class SmallMsgCompressor { public byte[] pack(byte[] body) { byte[] z Zstd.compress(body, 3); // 壓縮后還要在頭部寫原始長(zhǎng)度、算法標(biāo)記等元信息 ByteBuffer buf ByteBuffer.allocate(4 1 z.length) .putInt(body.length).put((byte) 1).put(z).array(); return buf; } }逐行解釋- 第 5 行ByteBuffer.allocate(4 1 z.length)壓縮后我們額外加了 4 字節(jié)原始長(zhǎng)度 1 字節(jié)算法標(biāo)記。對(duì) 200 字節(jié)的小消息Zstd 壓縮比只有 1.1 左右加上 5 字節(jié)頭整體反而比原文大。- 更隱蔽的壓縮算法為了建字典/寫幀頭小數(shù)據(jù)常有固定開銷幾字節(jié)到幾十字節(jié)數(shù)據(jù)越短越不劃算。我們測(cè)過單條 512 字節(jié)的消息Zstd 級(jí)別 3 平均膨脹 6% 4KB 才開始穩(wěn)定收益。- 修法是「設(shè)閾值 批量」單條 1KB 不壓縮直接發(fā)或者把多條消息攢成一批比如 64KB 一個(gè) batch再壓批內(nèi)冗余多、壓縮比直接到 3.5 以上。我們改成批量壓縮后MQ 帶寬降了 58%比逐條壓還省。第三個(gè)坑壓縮級(jí)別和「數(shù)據(jù)特征」強(qiáng)相關(guān)壓縮比不是算法單方面決定的和你的數(shù)據(jù)冗余度強(qiáng)相關(guān)。我們同一套 Zstd 級(jí)別 3- 應(yīng)用日志大量重復(fù)字段名、堆棧壓縮比 3.4- 已壓縮過的圖片 base64 / gzip 過的上游報(bào)文壓縮比 0.98幾乎不壓甚至略膨脹- JSON 里塞了隨機(jī) UUID、簽名串的壓縮比 1.3這是很多人忽略的如果你要壓的數(shù)據(jù)本身已經(jīng)「很隨機(jī)」加密、base64 二進(jìn)制、UUID 滿天飛上什么壓縮算法都白搭CPU 白燒。我們的做法是「壓縮前先判斷數(shù)據(jù)類型」——帶application/octet-stream或已知已壓縮的直接跳過壓縮。這條規(guī)則上線后采集 agent 的無效壓縮 CPU 又降了 12%。第四個(gè)坑解壓側(cè)的 CPU 也是錢別只算壓縮側(cè)選算法時(shí)大家只盯著「壓縮快不快」忘了「解壓」也要 CPU。我們的日志進(jìn) Kafka 后在 Flink 消費(fèi)端解壓如果生產(chǎn)者用 Zstd 19 級(jí)壓縮消費(fèi)者解壓雖然比壓縮快得多但 Kafka 分區(qū)多、并行度高累積解壓 CPU 也不小。LZ4/Zstd 的解壓都極快比壓縮快一個(gè)量級(jí)Snappy 也是三者解壓側(cè)差異不大真正要警惕的是「生產(chǎn)者高壓縮級(jí)別」會(huì)放大「消費(fèi)者解壓總量」。所以級(jí)別選擇要站在「全鏈路 CPU 賬單」看不是只看發(fā)送端。應(yīng)用層壓縮 vs HTTP 傳輸層壓縮該壓哪一層我們有個(gè)接口既在應(yīng)用層用 Zstd 壓了 body又開著 Nginx 的gzip on結(jié)果是「壓縮兩次」——應(yīng)用層壓完的字節(jié)流對(duì) gzip 來說已經(jīng)是高熵隨機(jī)數(shù)據(jù)gzip 幾乎壓不動(dòng)還多燒 CPU純虧。我的取舍很直接要么在傳輸層統(tǒng)一 gzip/brHTTP 天生支持客戶端透明解壓要么在應(yīng)用層壓適合進(jìn) Kafka/Redis 這種不帶傳輸層壓縮的通道二選一別疊加。我們最終定對(duì)外 HTTP 接口走 Nginxbrbrotli比 gzip 還狠一點(diǎn)關(guān)掉應(yīng)用層壓縮對(duì)內(nèi) Kafka/Redis 走應(yīng)用層 Zstd 級(jí)別 3。這條規(guī)則上線后應(yīng)用層壓縮的 CPU 全省了對(duì)外接口帶寬靠 br 一樣省下來沒損失。還有一個(gè)常被問的壓縮級(jí)別和耗時(shí)到底是不是線性我們壓過一組日志單條 800 字節(jié)10 萬條批量Zstd 級(jí)別 1壓縮比 3.1單條 5μsZstd 級(jí)別 3壓縮比 3.4單條 8μsZstd 級(jí)別 6壓縮比 3.6單條 22μsZstd 級(jí)別 19壓縮比 3.9單條 210μs你看級(jí)別 1→3壓縮比漲 10%、耗時(shí)漲 60%還能接受3→19 壓縮比只漲 15%、耗時(shí)漲 26 倍完全不劃算。這條曲線就是我們定級(jí)別 3 的硬依據(jù)過了 3每多一分壓縮比都要幾十倍的 CPU 換。壓縮失敗要有回退壓完比原文還大就發(fā)原文第四坑之后補(bǔ)一條工程紀(jì)律壓縮不是「壓了就一定發(fā)壓縮版」要比較壓縮后和原文大小膨脹就回退原文。我們工具類最終長(zhǎng)這樣public class SafeCompressor { public CompressResult pack(byte[] raw, int level) { byte[] z Zstd.compress(raw, level); // 壓完比原文還大小數(shù)據(jù)常見直接發(fā)原文省一次誤事 if (z.length raw.length) { return CompressResult.raw(raw); } return CompressResult.compressed(z, raw.length); } }逐行解釋- 第 5 行if (z.length raw.length)是回退閘門小數(shù)據(jù)、隨機(jī)數(shù)據(jù)壓縮后常常比原文大這時(shí)候發(fā)壓縮版既費(fèi) CPU 又費(fèi)帶寬不如直接發(fā)原文。我們線上小消息占比 30%加這層后這部分流量不再無效壓縮。- 第 6 行返回CompressResult.raw(raw)時(shí)要在協(xié)議頭里標(biāo)「未壓縮」消費(fèi)端按標(biāo)記決定解不解壓。壓縮/未壓縮必須帶標(biāo)記否則解壓端不知道該不該解——這是自研壓縮通道最容易漏的一環(huán)。復(fù)盤真實(shí)數(shù)字Zstd 級(jí)別 19單條壓縮 8μs → 210μs采集 agent CPU 15% → 100%同機(jī)訂單服務(wù) P99 漲了 40%。降到級(jí)別 3帶寬節(jié)省從 19 級(jí)的「省 74%」變成「省 70%」但 CPU 回到 18%P99 恢復(fù)正?！? 個(gè)百分點(diǎn)的壓縮比不值 85% 的 CPU。小消息改批量壓縮64KB/batchMQ 帶寬再降 58%相比逐條壓。跳過「已壓縮/隨機(jī)數(shù)據(jù)」無效壓縮 CPU 再降 12%。我的取舍壓縮是 CPU?帶寬的置換別替一方代言我不建議無腦上最高壓縮級(jí)別。先問自己兩件事瓶頸在帶寬還是 CPU數(shù)據(jù)冗余度高不高帶寬貴、數(shù)據(jù)冗余高、且實(shí)時(shí)性要求一般 → Zstd 1~3 或 LZ4CPU 已經(jīng)緊張 → LZ4 優(yōu)先別碰 Zstd 高檔離線冷存、幾乎不壓縮 → Zstd 19 隨便用。小數(shù)據(jù)先攢批或設(shè)閾值別逐條壓已壓縮/隨機(jī)數(shù)據(jù)直接跳過壓縮。一句話壓縮級(jí)別調(diào)高之前先量「每多 1% 壓縮比要燒多少 CPU」多數(shù)時(shí)候級(jí)別 3 就是甜區(qū)再往上純屬給賬單添堵。思考題如果你的消息總線里 80% 是 512 字節(jié)的小消息、20% 是大報(bào)文你會(huì)統(tǒng)一壓縮還是按大小分流分流的閾值怎么定才不引入新的判斷開銷