戰(zhàn)：原理、參數(shù)調(diào)優(yōu)與避坑指南)
1. 先把LZMA這個(gè)算法給看明白看到LZMA這個(gè)詞玩過數(shù)據(jù)壓縮的應(yīng)該都不陌生——不管是7-Zip里的.7z文件還是Linux下常見的.xz包底層基本都是這套LZMA算法在扛大旗。它是Lempel-Ziv-Markov chain Algorithm的縮寫常被歸類到LZ系算法的大樹下但實(shí)際實(shí)現(xiàn)里并不是簡(jiǎn)單套用LZ77就完事而是在LZ77滑窗匹配的基礎(chǔ)上疊加了上下文建模和區(qū)間編碼。簡(jiǎn)單說(shuō)這套算法在做兩件事先用字典在局部窗口里找重復(fù)再用概率模型對(duì)剩余的信息做更精細(xì)的壓縮。兩個(gè)環(huán)節(jié)配合下來(lái)壓縮率通常比傳統(tǒng)的DEFLATE就是gzip/zlib用的那套高出20%到40%。那這篇內(nèi)容講什么我打算從“這個(gè)算法到底怎么用”出發(fā)把每個(gè)環(huán)節(jié)拉通一遍它的原理骨架、開發(fā)環(huán)境怎么搭、關(guān)鍵參數(shù)怎么配、實(shí)際編碼和解壓的完整流程、以及我在項(xiàng)目里踩過的各種坑。不管你是做嵌入式固件升級(jí)包、游戲資源熱更、還是后端日志歸檔只要手頭有二進(jìn)制數(shù)據(jù)需要壓得更小這套內(nèi)容基本都能直接遷過去用。先說(shuō)個(gè)總體的判斷LZMA不是一個(gè)“無(wú)腦調(diào)高等級(jí)就完事”的算法它最大的特點(diǎn)叫作“壓縮率上限高”副作用是“CPU消耗大、內(nèi)存占用高”。在我的實(shí)際測(cè)試?yán)锿瑯拥臄?shù)據(jù)gzip -9壓出來(lái)大概還有10MBLZMA 9級(jí)能壓到7MB左右但是壓縮時(shí)間會(huì)是gzip的好幾倍甚至十幾倍。所以選型的時(shí)候必須想清楚你的場(chǎng)景到底是“壓完存很久、解壓次數(shù)多”還是“壓縮頻繁、解壓也頻繁”。前者選LZMA很劃算后者可能用zstd更理性。適合看這篇內(nèi)容的人包括但不限于被老板逼著做安裝包瘦身的客戶端開發(fā)、搗鼓自定義資源格式的游戲引擎工程師、給云服務(wù)做數(shù)據(jù)管線的后端同學(xué)、以及想弄明白LZMA和普通zip到底差在哪的愛好者。我會(huì)盡量把每個(gè)細(xì)節(jié)講得“可落地”不是給你堆理論而是給出一套能直接跑的方案和參數(shù)搭配。2. 核心原理與選型為什么偏偏是LZMA2.1 LZMA到底比“傳統(tǒng)LZ77”多了什么東西理解LZMA的第一站是搞明白它和經(jīng)典LZ77的區(qū)別。LZ77的核心思想不復(fù)雜一邊滑動(dòng)窗口掃描輸入數(shù)據(jù)一邊在窗口里找和當(dāng)前位置匹配的最長(zhǎng)重復(fù)片段把重復(fù)部分用“(距離, 長(zhǎng)度)”這一對(duì)數(shù)字替代。理論很干凈但具體落地時(shí)有個(gè)很大的痛點(diǎn)匹配信息本身的編碼效率不夠高。DEFLATE對(duì)距離和長(zhǎng)度做了Huffman編碼這已經(jīng)比裸整數(shù)強(qiáng)不少但依然存在“符號(hào)之間割裂”的問題距離、長(zhǎng)度、字面量之間的關(guān)系沒有被模型利用起來(lái)。LZMA則在匹配階段之后引入了一套馬爾可夫鏈建模。它把當(dāng)前字節(jié)、上下文歷史、匹配長(zhǎng)度等等狀態(tài)喂給概率預(yù)測(cè)器再由區(qū)間編碼器range coder把這些事件按照概率分布?jí)撼啥M(jìn)制比特流。概率越高的符號(hào)占用的bit越少。這就等于是用“一系列的預(yù)測(cè)器”取代了靜態(tài)的Huffman表。聽上去抽象你可以理解成DEFLATE是拿一種固定的編碼策略對(duì)付所有數(shù)據(jù)LZMA則是觀察著前文內(nèi)容不斷動(dòng)態(tài)修正自己的編碼策略。這樣的動(dòng)態(tài)建模給了LZMA一個(gè)非常明顯的優(yōu)勢(shì)它對(duì)高度自相關(guān)的文本、結(jié)構(gòu)化日志、二進(jìn)制配置數(shù)據(jù)、甚至一些接近隨機(jī)但存在局部規(guī)律的數(shù)據(jù)都能壓出比傳統(tǒng)算法更小的體積。代價(jià)你也猜到了——每一步編碼都要維護(hù)一堆概率狀態(tài)并做乘除運(yùn)算區(qū)間編碼的每一步都涉及處理比較重的高精度運(yùn)算壓縮和解壓的CPU開銷自然上去了。2.2 LZMA和LZMA2、.xz、.7z之間的關(guān)系這是我在實(shí)際交流中發(fā)現(xiàn)特別容易繞暈的地方。嚴(yán)格說(shuō)LZMA是一個(gè)編碼算法LZMA2是它的改進(jìn)版本主要解決了LZMA在“并行壓縮”和“大字典下內(nèi)存碎片”方面的短板。而.xz和.7z是容器格式類似zip和tar之間的關(guān)系容器負(fù)責(zé)把流分塊、加校驗(yàn)、存元信息流內(nèi)部才真正使用LZMA或LZMA2編碼。日常開發(fā)里區(qū)別還是很重要的。如果你調(diào)用Python的lzma模塊打開某個(gè).xz文件默認(rèn)走的是LZMA2如果你拿7-Zip工具去壓一個(gè).7z文件其實(shí)壓縮內(nèi)核既可能是LZMA也可能是LZMA2取決于你在壓縮選項(xiàng)里怎么選。至于那個(gè)后綴為.lzma的裸流一般不包含任何文件頭只有5個(gè)字節(jié)的屬性字段lc/lp/pb字典大小和8字節(jié)的解壓后大小后面緊跟壓縮數(shù)據(jù)。它和.xz容器不是一回事。所以做跨平臺(tái)對(duì)接的時(shí)候一定要提前確認(rèn)好對(duì)方用的是哪種封裝。我見過不止一次因?yàn)榘?xz文件硬改成.lzma后綴然后交給解壓庫(kù)結(jié)果解壓報(bào)錯(cuò)的情況。兩種容器的解析規(guī)則完全不同光是解壓后大小字段的位置就不一樣處理不好直接讀到一串莫名其妙的字節(jié)。提示如果你只是給某個(gè)工具鏈生成數(shù)據(jù)盡量首選.xz容器因?yàn)長(zhǎng)ZMA2在多數(shù)現(xiàn)代庫(kù)里有更好的兼容性和并行能力。只有當(dāng)你確認(rèn)目標(biāo)系統(tǒng)只有裸LZMA解碼器時(shí)才選擇.lzma流。2.3 什么場(chǎng)景值得用LZMA什么場(chǎng)景萬(wàn)萬(wàn)別用選型這件事不能只看壓縮率。我用一張表把典型場(chǎng)景和推薦等級(jí)列一下場(chǎng)景推薦度原因安裝包/固件包離線歸檔高體積敏感壓縮一次、解壓多次CPU開銷可接受海量日志歸并存儲(chǔ)高文本自相關(guān)性強(qiáng)LZMA壓縮率優(yōu)勢(shì)明顯盤錢省不少數(shù)據(jù)庫(kù)備份快照高一次性壓縮長(zhǎng)期保存壓縮率直接決定存儲(chǔ)費(fèi)用游戲資源包熱更中依賴解壓速度LZMA解壓還行但內(nèi)存開銷要注意實(shí)時(shí)網(wǎng)絡(luò)傳輸壓縮低CPU占用太高延遲容易失控建議zstd/deflate嵌入式MCU受限環(huán)境低字典內(nèi)存動(dòng)輒幾十MB很多單片機(jī)根本扛不住超高頻寫入的KV系統(tǒng)低壓縮成本會(huì)讓寫入P99成倍惡化從我自己的經(jīng)驗(yàn)看LZMA最舒服的位置在于“一次壓縮、多次讀取”尤其是資源包、固件這類再也不變更的數(shù)據(jù)。反之凡是要求毫秒級(jí)壓縮響應(yīng)、或者寫入路徑吞吐極高的系統(tǒng)我會(huì)第一時(shí)間排除LZMA轉(zhuǎn)而選用zstd這種更懂的平衡的算法。3. 參數(shù)細(xì)節(jié)拆解該動(dòng)哪些、不該動(dòng)哪些3.1 level到底代表什么別只盯著0到9很多庫(kù)都提供了類似“壓縮級(jí)別”的參數(shù)LZMA也不例外。7-Zip SDK里的LzmaCompress接口通過level指定壓縮力度最樸素的理解是level越大壓縮率越高、速度越慢。但底層實(shí)際發(fā)生的變化涉及三塊字典大小、匹配查找器match finder、以及搜索深度。比如level 1默認(rèn)用256KB字典匹配查找器是HC3level 9默認(rèn)用64MB字典匹配查找器是BT4。這些參數(shù)直接決定了壓縮內(nèi)存和壓縮耗時(shí)。實(shí)際項(xiàng)目中我很少直接把level拉滿。原因很簡(jiǎn)單level 9的壓縮率比level 8高不了幾個(gè)百分點(diǎn)耗時(shí)卻往往翻倍。從工程平衡性來(lái)說(shuō)多數(shù)歸檔場(chǎng)景用level 7到8最劃算。而如果你的產(chǎn)物要分發(fā)到內(nèi)存受限的設(shè)備上解壓level反而沒那么關(guān)鍵——解壓內(nèi)存主要取決于解壓方設(shè)置的最大字典上限而不是壓縮時(shí)用的level。這里提個(gè)醒LZMA的編碼器和解碼器對(duì)字典大小有隱式對(duì)齊要求編碼端用的字典如果超過了解碼端允許的最大值解碼器會(huì)直接拒絕或者崩潰。所以在分發(fā)場(chǎng)景里你一定要在壓縮時(shí)明確指定字典上限而不是默認(rèn)隨level走。3.2 lc、lp和pb三個(gè)屬性到底改變了什么這三個(gè)參數(shù)是大伙最頭疼的。lc是字面量上下文位數(shù)lp是字面量位置位數(shù)pb是位置位數(shù)。它們的組合決定了上下文模型怎么區(qū)分“當(dāng)前字節(jié)該用哪一棵概率樹”。默認(rèn)值是lc3、lp0、pb2適用范圍很廣。我簡(jiǎn)單說(shuō)說(shuō)每個(gè)的作用lc建?！扒耙粋€(gè)字是什么”對(duì)預(yù)測(cè)當(dāng)前字的影響。文本類的數(shù)據(jù)增大lc往往有收益但也更吃CPU。lp建?！爱?dāng)前處于什么對(duì)齊位置”對(duì)預(yù)測(cè)的影響。二進(jìn)制結(jié)構(gòu)數(shù)據(jù)比如4字節(jié)對(duì)齊的結(jié)構(gòu)體里增大lp有時(shí)會(huì)帶來(lái)驚喜。pb建?！熬嚯x上一個(gè)匹配多遠(yuǎn)的位置”對(duì)預(yù)測(cè)的影響。這個(gè)值越高匹配距離的建模粒度越細(xì)。三者的總合法范圍是lc lp ≤ 4pb ≤ 4。超出這個(gè)限制編碼器直接就報(bào)參數(shù)錯(cuò)誤。大多數(shù)情況下我建議你直接用默認(rèn)值除非你帶著“內(nèi)存受限但壓縮率還要過一條線”的目標(biāo)去調(diào)。比如某次做嵌入式配置包我把lc從3調(diào)到4pb保持2發(fā)現(xiàn)配置類數(shù)據(jù)的壓縮率立刻好了3%不到但解碼內(nèi)存占用略微上升?？傮w收益不明顯所以后來(lái)我還是回到了默認(rèn)。3.3 字典大小壓縮內(nèi)存與壓縮率的根本交易字典大小dictSize是LZMA最核心的內(nèi)存參數(shù)。編碼端為了讓最多重復(fù)數(shù)據(jù)被匹配需要維護(hù)一個(gè)hash鏈表和查找結(jié)構(gòu)這個(gè)結(jié)構(gòu)的大小通常是字典大小的數(shù)倍?？?-Zip SDK源碼的話LzFind.c里那個(gè)hash表的分配就能看出來(lái)內(nèi)存大頭主要花在hash table和bt tree的節(jié)點(diǎn)分配上。實(shí)際經(jīng)驗(yàn)值編碼端內(nèi)存是字典大小的5到10倍64MB字典意味著編碼內(nèi)存可能沖上300MB以上。解壓端又要小得多因?yàn)長(zhǎng)ZMA解壓只需要維護(hù)一個(gè)字典循環(huán)緩沖區(qū)其大小就是字典上限。這也正是LZMA適合“打包一次、多端解壓”的重要原因?？扇绻阍趬嚎s時(shí)用了64MB字典但在目標(biāo)設(shè)備上把解壓緩沖限制成16MB那解壓直接就失敗。解決方案有兩種壓縮端主動(dòng)把字典調(diào)低或者解壓端按壓縮頭里的數(shù)值自適應(yīng)分配。我個(gè)人的習(xí)慣是給PC客戶端分發(fā)時(shí)字典上限給16MB到32MB給手機(jī)App資源熱更時(shí)壓到8MB老一點(diǎn)的低端Android設(shè)備我甚至?xí)旱?MB。壓縮率會(huì)損失一些但換來(lái)的是所有目標(biāo)機(jī)器都能穩(wěn)解這是值得的。實(shí)踐心得參數(shù)表的含義在官方SDK的LzmaEnc.c里面都有注釋但千萬(wàn)不要照搬示例里的“預(yù)估解壓內(nèi)存dictSize 一些余量”真實(shí)的嵌入式環(huán)境建議自己壓一個(gè)上限數(shù)據(jù)做壓力測(cè)試。4. 實(shí)操落地從壓縮到解壓的完整閉環(huán)4.1 語(yǔ)言與庫(kù)選型你可以從哪里起步動(dòng)手階段先解決“用什么庫(kù)”的問題。這里分語(yǔ)言說(shuō)因?yàn)楹芏嗳藭?huì)被SDK風(fēng)格勸退C/C官方7-Zip SDK里的LzmaEnc.c和LzmaDec.c是最原始、最純正的實(shí)現(xiàn)直接拿源碼編進(jìn)工程就行。缺點(diǎn)是API風(fēng)格老派、錯(cuò)誤碼不夠直觀。LzmaUtil.c這個(gè)示例工程是很好的學(xué)習(xí)起點(diǎn)。Python直接使用標(biāo)準(zhǔn)庫(kù)lzma模塊即可。這對(duì)于快速驗(yàn)證、自動(dòng)化腳本、車載數(shù)據(jù)處理都非常方便不需要安裝任何第三方依賴。pickle序列化后的對(duì)象也可以直接用lzma壓縮保存省事。Java/Kotlin有一個(gè)叫xz的開源庫(kù)它在Java生態(tài)里很常見支持LZMA1、LZMA2和.xz容器。Android端集成也不難。Go官方標(biāo)準(zhǔn)庫(kù)不支持LZMA需要引入第三方庫(kù)實(shí)現(xiàn)常見的方案里性能一般瓶頸在純Go實(shí)現(xiàn)。如果你想在項(xiàng)目里快速出活我的建議流程是先用Python把數(shù)據(jù)和參數(shù)跑通確認(rèn)壓縮率符合預(yù)期再遷移到C/C或者目標(biāo)語(yǔ)言做生產(chǎn)級(jí)實(shí)現(xiàn)。這樣能避免一上來(lái)就陷進(jìn)C API的參數(shù)設(shè)置和內(nèi)存管理里出不來(lái)。4.2 Python快速實(shí)踐十分鐘跑通壓縮解壓Python的lzma模塊之所以好用是因?yàn)樗押芏嗉?xì)節(jié)都封裝好了。下面這段代碼是我常用的最小模板兼顧了壓縮、解壓和參數(shù)控制import lzma import os # 壓縮 data b這是一段用于測(cè)試LZMA壓縮的文本數(shù)據(jù)。 * 10000 compressed lzma.compress( data, formatlzma.FORMAT_ALONE, # 裸LZMA流不是.xz容器 filters[{ id: lzma.FILTER_LZMA1, preset: 7, # 壓縮預(yù)設(shè)等級(jí) dict_size: 1 26, # 64MB字典注意內(nèi)存 lc: 3, lp: 0, pb: 2, }], ) print(f原始大小: {len(data)}) print(f壓縮后大小: {len(compressed)}) print(f壓縮率: {len(compressed) / len(data) * 100:.2f}%) # 解壓 decompressed lzma.decompress( compressed, formatlzma.FORMAT_ALONE, ) assert decompressed data, 數(shù)據(jù)不一致 print(解壓成功數(shù)據(jù)完全一致)這里有個(gè)非常關(guān)鍵的點(diǎn)FORMAT_ALONE對(duì)應(yīng)的是裸LZMA流默認(rèn)的FORMAT_XZ對(duì)應(yīng)的是.xz容器。如果壓縮用ALONE、解壓用默認(rèn)的FORMAT_XZ會(huì)直接拋錯(cuò)。另外preset和dict_size同時(shí)指定時(shí)dict_size會(huì)覆蓋預(yù)設(shè)里的默認(rèn)字典這是精確控制資源占用的好辦法。如果你不想手動(dòng)配filters直接lzma.compress(data, preset9)也行但此時(shí)你無(wú)法控制字典上限內(nèi)存占用不受你把控。線上服務(wù)里我?guī)缀醵际菐е鴉ilters參數(shù)顯式指定目的就是避免某次代碼調(diào)整把壓縮任務(wù)的內(nèi)存打到2GB。4.3 C接口核心流程別被LzmaCompress的參數(shù)嚇到切換到C/C時(shí)主要API是LzmaCompress和LzmaUncompress。前者位于LzmaLib.h里函數(shù)簽名挺長(zhǎng)核心調(diào)用方式如下#include stdio.h #include string.h #include LzmaLib.h #define IN_BUF_SIZE (1 20) #define OUT_BUF_SIZE (1 20) int main(void) { // 原始數(shù)據(jù)實(shí)際項(xiàng)目中從文件或網(wǎng)絡(luò)讀取 unsigned char in_data[IN_BUF_SIZE]; memset(in_data, A, sizeof(in_data)); // 準(zhǔn)備壓縮輸出緩沖區(qū) unsigned char out_props[5]; size_t out_props_size sizeof(out_props); unsigned char *out_data malloc(IN_BUF_SIZE IN_BUF_SIZE / 3 128); size_t out_data_size malloc_usable_size(out_data); if (!out_data) return -1; int level 7; unsigned dict_size 1 24; // 16MB int lc 3, lp 0, pb 2; unsigned fb 273; int algo 1; // 0fast, 1normal unsigned bt_mode 1; int ret LzmaCompress( out_data, out_data_size, in_data, sizeof(in_data), out_props, out_props_size, level, dict_size, lc, lp, pb, fb, algo, bt_mode ); if (ret ! SZ_OK) { fprintf(stderr, 壓縮失敗錯(cuò)誤碼: %d\n, ret); free(out_data); return -1; } printf(壓縮后大小: %zu bytes\n, out_data_size); free(out_data); return 0; }這段代碼自動(dòng)選擇壓縮級(jí)別但它引出了另一個(gè)問題C接口解壓時(shí)怎么知道壓縮流屬性答案是先讀那5個(gè)字節(jié)的out_props。解碼端拿到這5個(gè)字節(jié)后傳入LzmaUncompress才能正確初始化解壓狀態(tài)。裸LZMA流的5字節(jié)屬性中第0字節(jié)是(lc, lp, pb)的打包結(jié)果后4字節(jié)是小端序的字典大小。這個(gè)結(jié)構(gòu)極其重要但也極其容易出錯(cuò)。我的經(jīng)驗(yàn)是在上層協(xié)議里把這5字節(jié)和8字節(jié)的解壓大小作為自定義頭部一并存儲(chǔ)或傳輸。比如做成一個(gè)24字節(jié)的文件頭5字節(jié)屬性、8字節(jié)原始大小、4字節(jié)文件名長(zhǎng)度、剩余是文件名和壓縮數(shù)據(jù)。這樣解壓端不需要額外約定就能完成精確的動(dòng)態(tài)分配和狀態(tài)初始化。4.4 使用.xz容器時(shí)的流式處理生產(chǎn)環(huán)境里數(shù)據(jù)往往不可能一次性全部載入內(nèi)存這時(shí)候“流式編碼/解碼”就派上用場(chǎng)了。Python的lzma模塊對(duì).xz容器支持得很順手配合LZMAFile可以一邊讀一邊寫內(nèi)存始終維持低位import lzma # 流式壓縮邊讀邊寫 with open(large.bin, rb) as fin, lzma.open(large.bin.xz, wb, preset7) as fout: while True: chunk fin.read(1 20) # 每次處理1MB if not chunk: break fout.write(chunk) # 流式解壓邊讀邊還原 with lzma.open(large.bin.xz, rb) as fin, open(restored.bin, wb) as fout: while True: chunk fin.read(1 20) if not chunk: break fout.write(chunk)但請(qǐng)注意裸LZMA流不支持這種流式操作因?yàn)長(zhǎng)ZMA編碼器必須持續(xù)維護(hù)上下文產(chǎn)生的是“有狀態(tài)”的連續(xù)字節(jié)流——拿Python的lzma.decompress去處理裸流時(shí)通常仍然是整塊整塊喂進(jìn)去。如果你確實(shí)需要流式處理而且不想要.xz容器另一種思路是把大文件拆成多塊各自獨(dú)立做裸LZMA壓縮然后給每塊加上索引頭。這個(gè)方案的優(yōu)點(diǎn)是解壓端可以進(jìn)行隨機(jī)訪問缺點(diǎn)是壓縮率因?yàn)榍袎K而有所下降。切塊大小我常用4MB到16MB損耗通常在5%以內(nèi)。5. 高頻踩坑與排查經(jīng)驗(yàn)都是實(shí)測(cè)過才敢寫5.1 編碼屬性不一致解壓端直接拒絕這可能是最頻繁的現(xiàn)場(chǎng)事故?，F(xiàn)象是壓縮端用某個(gè)字典、lc/lp/pb組合壓縮解壓時(shí)如果屬性值不匹配LzmaUncompress會(huì)報(bào)錯(cuò)或者更糟——不報(bào)錯(cuò)卻輸出一堆錯(cuò)亂數(shù)據(jù)。裸LZMA之所以要把5字節(jié)屬性放在最前面就是讓解碼端按屬性初始化?？梢坏┯腥藞D省事把屬性硬編碼成固定值數(shù)據(jù)流一變就翻車。我在一個(gè)模擬項(xiàng)目X里就碰到過模塊A用默認(rèn)屬性壓縮模塊B解壓時(shí)把屬性寫死了結(jié)果版本升級(jí)后壓縮端換了字典大小線上解壓率瞬間變成100%失敗。修法也不復(fù)雜——解壓端嚴(yán)格讀取流里的屬性字節(jié)而不是自己猜。5.2 解壓輸出緩沖大小別拿壓縮后大小當(dāng)解壓大小裸LZMA編碼頭里那8字節(jié)的uncompressed size作用是告訴解壓端“總共要解多大”。但很多文檔說(shuō)這個(gè)值可以為0表示未知。一旦為0LzmaUncompress就沒了目標(biāo)長(zhǎng)度參照必須靠循環(huán)反復(fù)喂數(shù)據(jù)。在這個(gè)模式下解壓端要特別注意輸出緩沖的擴(kuò)容邏輯否則會(huì)不斷遇到SZ_ERROR_OUTPUT_EOF。我的建議無(wú)論使用什么語(yǔ)言都盡量在壓縮頭里保留真實(shí)的原始大小。巧的是LZMA SDK需要在壓縮前就把原始大小傳進(jìn)去所以“流式壓縮且不知道原始大小”本身就是個(gè)矛盾場(chǎng)景。通常的工程化解法是先寫入一個(gè)臨時(shí)文件或者先在內(nèi)存里匯總再回頭填大小字段。5.3 多線程壓縮遠(yuǎn)沒有想象的那么美LZMA對(duì)每個(gè)獨(dú)立的數(shù)據(jù)塊進(jìn)行壓縮時(shí)是可以并行的LZMA2就支持分塊獨(dú)立編碼因此天然適合多線程。但如果你用的是裸LZMA它是一條有狀態(tài)的連續(xù)流只有單線程實(shí)現(xiàn)。很多人在服務(wù)端想用裸LZMA壓縮大文件發(fā)現(xiàn)CPU只有一個(gè)核在跑這就是本質(zhì)原因。所以要做并行壓縮請(qǐng)優(yōu)先用LZMA2或直接切成多塊獨(dú)立壓縮。用Python時(shí)最簡(jiǎn)單的并行方案如下import lzma from concurrent.futures import ThreadPoolExecutor def compress_chunk(chunk): return lzma.compress(chunk, formatlzma.FORMAT_XZ, preset6) chunks [block_0, block_1, block_2] with ThreadPoolExecutor(max_workers4) as pool: compressed_chunks list(pool.map(compress_chunk, chunks))但這里要權(quán)衡切塊越小塊與塊之間的歷史參考越少壓縮率下降越多。切塊越大并行度越低。我用過的穩(wěn)妥方案是單塊1MB到4MB四線程并行壓縮率損失能控制在3%到6%之間同時(shí)吞吐能提升三倍以上。5.4 解壓失敗“數(shù)據(jù)損壞”的真兇內(nèi)存碎塊C接口下高頻次壓縮小數(shù)據(jù)時(shí)即便邏輯看起來(lái)完全正確也偶爾會(huì)偶發(fā)SZ_ERROR_DATA錯(cuò)誤。排查了很久我才明白問題出在SDK使用了一個(gè)自定義內(nèi)存分配器它默認(rèn)依賴系統(tǒng)malloc但要求緩沖區(qū)對(duì)齊。當(dāng)整個(gè)系統(tǒng)長(zhǎng)時(shí)間運(yùn)行、內(nèi)存碎片嚴(yán)重時(shí)分配器拿到的內(nèi)存塊邊界可能不理想導(dǎo)致區(qū)間編碼器的讀寫出問題。這不是算法本身的問題而是工程集成的問題。修法有兩個(gè)方向一是改用SDK自帶的Alloc和Free函數(shù)指針注入穩(wěn)定的內(nèi)存池二是干脆把單次分配大小固定下來(lái)避免頻繁變長(zhǎng)分配。我親手經(jīng)歷過某設(shè)備上報(bào)的偶發(fā)解壓失敗就是在統(tǒng)一了分配器策略之后徹底消失的。5.5 進(jìn)度條到底應(yīng)該怎么算壓縮任務(wù)的進(jìn)度好算因?yàn)榫幋a端知道讀了多少輸入、寫了多少輸出。解壓進(jìn)度是玄學(xué)——尤其是裸LZMA雖然頭里有8字節(jié)的原始大小但在解壓完成前你無(wú)法知道當(dāng)前輸出相對(duì)于最終大小的準(zhǔn)確比例因?yàn)閰^(qū)間解碼器必須把所有的bit都消費(fèi)完才知道準(zhǔn)確位置。實(shí)際中我做進(jìn)度條采用的是“塊級(jí)百分比”如果數(shù)據(jù)被設(shè)計(jì)成多塊獨(dú)立壓縮結(jié)構(gòu)每解完一個(gè)塊就按塊比例更新進(jìn)度。如果是單條LZMA流那就只能拿“已解壓字節(jié)數(shù) / 頭部聲明的原始大小”估算。后者在某種程度上是準(zhǔn)的但由于LZMA解碼器輸出和輸入之間存在緩沖窗尾部會(huì)有幾KB的滯后顯示。5.6 字典過大導(dǎo)致內(nèi)存申請(qǐng)失敗這件事在32位進(jìn)程和嵌入式平臺(tái)上尤其常見。某次我在老設(shè)備上集成LZMA解壓壓縮端發(fā)來(lái)一個(gè)64MB字典的流解碼端按規(guī)定申請(qǐng)了64MB緩沖加上系統(tǒng)其他模塊的內(nèi)存開銷直接觸發(fā)OOM。現(xiàn)象是解壓到一半進(jìn)程被殺沒有任何錯(cuò)誤日志。這給我們的教訓(xùn)是在分布式或跨設(shè)備傳輸數(shù)據(jù)的項(xiàng)目里解壓上限永遠(yuǎn)是參與方共同約定的協(xié)議字段。壓縮方不能只考慮自己的性能必須知道對(duì)端能承受的最大字典是多少。我經(jīng)常做的一個(gè)動(dòng)作就是在壓縮參數(shù)前加一道“目標(biāo)能力校驗(yàn)”把字典上限作為一個(gè)配置文件下發(fā)到編碼端禁止本地隨意改大。6. 進(jìn)階玩法把LZMA揉進(jìn)你的業(yè)務(wù)架構(gòu)6.1 隨機(jī)訪問壓縮包分塊裸流索引表如果你要壓縮一個(gè)很大的數(shù)據(jù)集又希望解壓端能直接讀取中間某一段而不是從頭解到尾可以考慮“分塊裸流外部索引”的結(jié)構(gòu)。也就是把數(shù)據(jù)按固定大小切塊逐個(gè)裸LZMA壓縮每塊頭部記錄塊號(hào)、原始偏移、壓縮偏移、壓縮后大小。讀取時(shí)根據(jù)目標(biāo)偏移定位塊號(hào)只解壓那一塊。這種方案的壓縮率比整體壓縮低一些但數(shù)據(jù)中心場(chǎng)景里的收益非常大。我做過一個(gè)模擬數(shù)據(jù)倉(cāng)庫(kù)原先查詢某個(gè)字段要解壓整個(gè)300MB的包耗時(shí)十幾秒改成分塊之后定位到目標(biāo)塊只要幾百毫秒體驗(yàn)完全是兩碼事。切塊大小我通常按“單塊原始數(shù)據(jù)4MB、壓縮后約1到2MB”來(lái)設(shè)太大失去隨機(jī)訪問意義太小會(huì)讓索引表膨脹。6.2 對(duì)加密數(shù)據(jù)做壓縮順序別搞反“先加密還是先壓縮”是每個(gè)架構(gòu)師都要回答的問題。如果你是先加密再壓縮加密后的字節(jié)流近似均勻隨機(jī)LZMA根本找不到冗余壓縮率接近無(wú)。正確的姿勢(shì)是先壓縮后加密。這讓壓縮算法能盡可能多地消除數(shù)據(jù)冗余然后再交給加密層去保證機(jī)密性。但這里有一個(gè)現(xiàn)實(shí)悖論如果原始數(shù)據(jù)本身就是強(qiáng)隨機(jī)的比如已經(jīng)是加密后的數(shù)據(jù)LZMA壓了幾乎等于沒壓反而白白消耗CPU。所以業(yè)務(wù)上一定要分類壓縮層只處理那些“明文里包含可壓縮冗余”的數(shù)據(jù)。如果某些字段是密文那直接跳過壓縮環(huán)節(jié)省掉無(wú)意義的CPU和時(shí)間開銷。6.3 使用LZMA做協(xié)議級(jí)壓縮時(shí)的“包大小”陷阱在RPC或者消息隊(duì)列里用LZMA壓縮小包經(jīng)常會(huì)出現(xiàn)“越壓越大”的現(xiàn)象。原因是LZMA有概率模型初始化的固定開銷對(duì)于小于幾百字節(jié)的數(shù)據(jù)模型還沒來(lái)得及建立優(yōu)勢(shì)就已經(jīng)結(jié)束了。這類場(chǎng)景下壓縮后體積很可能超過原始數(shù)據(jù)。我一般會(huì)設(shè)一個(gè)閾值原始包小于2KB時(shí)直接透?jìng)鞔笥?KB才嘗試壓縮。這個(gè)閾值對(duì)LZMA特別重要因?yàn)樗皇堑脱舆t算法。真實(shí)項(xiàng)目里有一次我看到某個(gè)消息網(wǎng)關(guān)在錯(cuò)誤地壓縮100字節(jié)左右的JSON包結(jié)果平均每條多出了80字節(jié)帶寬白白多耗了。加了閾值和最小收益判斷之后整體流量立刻回落。6.4 選擇.xz還是裸LZMA別為了“輕量”犧牲兼容性雖然裸LZMA流的封裝非常小只帶5字節(jié)屬性8字節(jié)大小很多人會(huì)覺得比.xz更省、更簡(jiǎn)單。但裸LZMA有兩個(gè)致命缺點(diǎn)沒有校驗(yàn)和、不支持流式并行。如果數(shù)據(jù)在傳輸或者存儲(chǔ)過程中損壞了一個(gè)bit編碼器無(wú)法自檢解壓時(shí)要么產(chǎn)生靜默錯(cuò)誤數(shù)據(jù)要么直接報(bào)錯(cuò)。而.xz容器自帶CRC64校驗(yàn)?zāi)軌蚋兄獡p壞并報(bào)錯(cuò)。所以我強(qiáng)烈建議凡是跑在有不可靠鏈路或者長(zhǎng)期存儲(chǔ)的設(shè)備上優(yōu)先選擇.xz容器格式。只有當(dāng)你需要極致最小的元數(shù)據(jù)、且上層協(xié)議已經(jīng)自帶校驗(yàn)時(shí)才考慮裸流。如果不是因?yàn)槟承├鲜紹ootloader只認(rèn)裸LZMA我可能根本不在生產(chǎn)項(xiàng)目里用裸流。7. 性能調(diào)優(yōu)把LZMA壓出最佳性價(jià)比7.1 壓縮級(jí)別選擇別迷信9很多人覺得壓縮率“越高越好”但LZMA的壓縮時(shí)間和壓縮率曲線并不是理想線性關(guān)系?；谀硞€(gè)20MB的混合數(shù)據(jù)測(cè)試得到一組典型數(shù)據(jù)如下配置壓縮時(shí)長(zhǎng)(秒)壓縮后大小(MB)說(shuō)明level 11.111.8適合臨時(shí)場(chǎng)景或極低內(nèi)存level 31.910.7性價(jià)比尚可level 52.810.1日常推薦level 75.29.4歸檔推薦level 911.79.1壓縮率提升極有限從7級(jí)升到9級(jí)壓縮率只好了3%左右耗時(shí)卻翻了約一倍。對(duì)于大多數(shù)業(yè)務(wù)歸檔用7到8級(jí)就夠了。如果服務(wù)器的CPU比較緊張用5級(jí)和7級(jí)的差距也不到10%但耗時(shí)差距明顯。壓縮率固然重要工程上始終要算總賬。7.2 字典大小的調(diào)優(yōu)路徑字典大小調(diào)整的核心思想是讓字典覆蓋數(shù)據(jù)的“局部重復(fù)跨度”。如果數(shù)據(jù)里最長(zhǎng)重復(fù)段只有幾KB那么1MB字典和64MB字典壓縮率幾乎相同后者只會(huì)白白浪費(fèi)內(nèi)存。如果你不確定可以按十倍經(jīng)驗(yàn)去試先用1MB再試4MB、16MB。觀察壓縮率的邊際收益一旦收益趨緩就停止增大。有一個(gè)更容易操作的方法是做一個(gè)“壓縮率-字典大小”的階梯測(cè)試腳本輸入真實(shí)樣本自動(dòng)輸出每次的壓縮率和耗時(shí)。我保留著這套小工具每次接新項(xiàng)目時(shí)都用它快速定基準(zhǔn)。它的實(shí)現(xiàn)非常簡(jiǎn)單核心就是用循環(huán)調(diào)用不同dict_size的compress然后打印結(jié)果。數(shù)據(jù)樣本最好用線上真實(shí)數(shù)據(jù)里抽樣拼接出來(lái)的不要用假數(shù)據(jù)否則你會(huì)得到一個(gè)完全沒有參考價(jià)值的曲線。7.3 解壓性能往往被忽視真正影響線上體驗(yàn)的是解壓速度。LZMA解壓速度大約在40MB/s到80MB/s的數(shù)量級(jí)視數(shù)據(jù)和CPU而定比gzip、zstd低不少。如果業(yè)務(wù)要求高頻讀取壓縮后的文件那么你優(yōu)化壓縮率收益也要同時(shí)接受解壓變慢的現(xiàn)實(shí)。我做過一個(gè)實(shí)驗(yàn)一個(gè)400MB的文本歸檔文件用LZMA壓縮成120MB解壓耗時(shí)6秒。換成zstd壓縮成160MB解壓只花1.5秒。如果這個(gè)文件每次服務(wù)啟動(dòng)都要加載一次那多出來(lái)的4.5秒就會(huì)直接出現(xiàn)在啟動(dòng)時(shí)間上。所以大型服務(wù)的配置文件、模型文件我更傾向于用zstd而不是LZMA換取更快的加載速度。8. 一點(diǎn)個(gè)人心得LZMA這套算法從1998年出現(xiàn)在7-Zip里到現(xiàn)在已經(jīng)二十多年但它在工程界的地位依然非常穩(wěn)。它不是用來(lái)解決所有數(shù)據(jù)的通用銀彈而是一個(gè)“在最大壓縮率和資源消耗之間需要深刻權(quán)衡”的專用工具。我對(duì)LZMA的總體印象是極端的壓縮率來(lái)自它對(duì)數(shù)據(jù)概率的極致建模這也意味著它不能像gzip那樣被無(wú)腦使用。真正穩(wěn)妥的做法始終是先理解數(shù)據(jù)特性、再明確資源邊界、最后選擇合適的封裝和參數(shù)。最后分享一個(gè)小技巧在團(tuán)隊(duì)內(nèi)部推廣LZMA方案時(shí)別只丟出一句“壓縮率好”最好做一個(gè)針對(duì)實(shí)際數(shù)據(jù)的對(duì)比表格把壓縮率、耗時(shí)、內(nèi)存峰值都列出來(lái)。多數(shù)情況下決定用不用LZMA的不是算法本身而是團(tuán)隊(duì)愿不愿意為那多出來(lái)的幾個(gè)百分點(diǎn)去增加資源開銷。數(shù)據(jù)說(shuō)話永遠(yuǎn)最有說(shuō)服力。 LZMA壓縮實(shí)戰(zhàn)：原理、參數(shù)調(diào)優(yōu)與避坑指南
1. 先把LZMA這個(gè)算法給看明白看到LZMA這個(gè)詞玩過數(shù)據(jù)壓縮的應(yīng)該都不陌生——不管是7-Zip里的.7z文件還是Linux下常見的.xz包底層基本都是這套LZMA算法在扛大旗。它是Lempel-Ziv-Markov chain Algorithm的縮寫常被歸類到LZ系算法的大樹下但實(shí)際實(shí)現(xiàn)里并不是簡(jiǎn)單套用LZ77就完事而是在LZ77滑窗匹配的基礎(chǔ)上疊加了上下文建模和區(qū)間編碼。簡(jiǎn)單說(shuō)這套算法在做兩件事先用字典在局部窗口里找重復(fù)再用概率模型對(duì)剩余的信息做更精細(xì)的壓縮。兩個(gè)環(huán)節(jié)配合下來(lái)壓縮率通常比傳統(tǒng)的DEFLATE就是gzip/zlib用的那套高出20%到40%。那這篇內(nèi)容講什么我打算從“這個(gè)算法到底怎么用”出發(fā)把每個(gè)環(huán)節(jié)拉通一遍它的原理骨架、開發(fā)環(huán)境怎么搭、關(guān)鍵參數(shù)怎么配、實(shí)際編碼和解壓的完整流程、以及我在項(xiàng)目里踩過的各種坑。不管你是做嵌入式固件升級(jí)包、游戲資源熱更、還是后端日志歸檔只要手頭有二進(jìn)制數(shù)據(jù)需要壓得更小這套內(nèi)容基本都能直接遷過去用。先說(shuō)個(gè)總體的判斷LZMA不是一個(gè)“無(wú)腦調(diào)高等級(jí)就完事”的算法它最大的特點(diǎn)叫作“壓縮率上限高”副作用是“CPU消耗大、內(nèi)存占用高”。在我的實(shí)際測(cè)試?yán)锿瑯拥臄?shù)據(jù)gzip -9壓出來(lái)大概還有10MBLZMA 9級(jí)能壓到7MB左右但是壓縮時(shí)間會(huì)是gzip的好幾倍甚至十幾倍。所以選型的時(shí)候必須想清楚你的場(chǎng)景到底是“壓完存很久、解壓次數(shù)多”還是“壓縮頻繁、解壓也頻繁”。前者選LZMA很劃算后者可能用zstd更理性。適合看這篇內(nèi)容的人包括但不限于被老板逼著做安裝包瘦身的客戶端開發(fā)、搗鼓自定義資源格式的游戲引擎工程師、給云服務(wù)做數(shù)據(jù)管線的后端同學(xué)、以及想弄明白LZMA和普通zip到底差在哪的愛好者。我會(huì)盡量把每個(gè)細(xì)節(jié)講得“可落地”不是給你堆理論而是給出一套能直接跑的方案和參數(shù)搭配。2. 核心原理與選型為什么偏偏是LZMA2.1 LZMA到底比“傳統(tǒng)LZ77”多了什么東西理解LZMA的第一站是搞明白它和經(jīng)典LZ77的區(qū)別。LZ77的核心思想不復(fù)雜一邊滑動(dòng)窗口掃描輸入數(shù)據(jù)一邊在窗口里找和當(dāng)前位置匹配的最長(zhǎng)重復(fù)片段把重復(fù)部分用“(距離, 長(zhǎng)度)”這一對(duì)數(shù)字替代。理論很干凈但具體落地時(shí)有個(gè)很大的痛點(diǎn)匹配信息本身的編碼效率不夠高。DEFLATE對(duì)距離和長(zhǎng)度做了Huffman編碼這已經(jīng)比裸整數(shù)強(qiáng)不少但依然存在“符號(hào)之間割裂”的問題距離、長(zhǎng)度、字面量之間的關(guān)系沒有被模型利用起來(lái)。LZMA則在匹配階段之后引入了一套馬爾可夫鏈建模。它把當(dāng)前字節(jié)、上下文歷史、匹配長(zhǎng)度等等狀態(tài)喂給概率預(yù)測(cè)器再由區(qū)間編碼器range coder把這些事件按照概率分布?jí)撼啥M(jìn)制比特流。概率越高的符號(hào)占用的bit越少。這就等于是用“一系列的預(yù)測(cè)器”取代了靜態(tài)的Huffman表。聽上去抽象你可以理解成DEFLATE是拿一種固定的編碼策略對(duì)付所有數(shù)據(jù)LZMA則是觀察著前文內(nèi)容不斷動(dòng)態(tài)修正自己的編碼策略。這樣的動(dòng)態(tài)建模給了LZMA一個(gè)非常明顯的優(yōu)勢(shì)它對(duì)高度自相關(guān)的文本、結(jié)構(gòu)化日志、二進(jìn)制配置數(shù)據(jù)、甚至一些接近隨機(jī)但存在局部規(guī)律的數(shù)據(jù)都能壓出比傳統(tǒng)算法更小的體積。代價(jià)你也猜到了——每一步編碼都要維護(hù)一堆概率狀態(tài)并做乘除運(yùn)算區(qū)間編碼的每一步都涉及處理比較重的高精度運(yùn)算壓縮和解壓的CPU開銷自然上去了。2.2 LZMA和LZMA2、.xz、.7z之間的關(guān)系這是我在實(shí)際交流中發(fā)現(xiàn)特別容易繞暈的地方。嚴(yán)格說(shuō)LZMA是一個(gè)編碼算法LZMA2是它的改進(jìn)版本主要解決了LZMA在“并行壓縮”和“大字典下內(nèi)存碎片”方面的短板。而.xz和.7z是容器格式類似zip和tar之間的關(guān)系容器負(fù)責(zé)把流分塊、加校驗(yàn)、存元信息流內(nèi)部才真正使用LZMA或LZMA2編碼。日常開發(fā)里區(qū)別還是很重要的。如果你調(diào)用Python的lzma模塊打開某個(gè).xz文件默認(rèn)走的是LZMA2如果你拿7-Zip工具去壓一個(gè).7z文件其實(shí)壓縮內(nèi)核既可能是LZMA也可能是LZMA2取決于你在壓縮選項(xiàng)里怎么選。至于那個(gè)后綴為.lzma的裸流一般不包含任何文件頭只有5個(gè)字節(jié)的屬性字段lc/lp/pb字典大小和8字節(jié)的解壓后大小后面緊跟壓縮數(shù)據(jù)。它和.xz容器不是一回事。所以做跨平臺(tái)對(duì)接的時(shí)候一定要提前確認(rèn)好對(duì)方用的是哪種封裝。我見過不止一次因?yàn)榘?xz文件硬改成.lzma后綴然后交給解壓庫(kù)結(jié)果解壓報(bào)錯(cuò)的情況。兩種容器的解析規(guī)則完全不同光是解壓后大小字段的位置就不一樣處理不好直接讀到一串莫名其妙的字節(jié)。提示如果你只是給某個(gè)工具鏈生成數(shù)據(jù)盡量首選.xz容器因?yàn)長(zhǎng)ZMA2在多數(shù)現(xiàn)代庫(kù)里有更好的兼容性和并行能力。只有當(dāng)你確認(rèn)目標(biāo)系統(tǒng)只有裸LZMA解碼器時(shí)才選擇.lzma流。2.3 什么場(chǎng)景值得用LZMA什么場(chǎng)景萬(wàn)萬(wàn)別用選型這件事不能只看壓縮率。我用一張表把典型場(chǎng)景和推薦等級(jí)列一下場(chǎng)景推薦度原因安裝包/固件包離線歸檔高體積敏感壓縮一次、解壓多次CPU開銷可接受海量日志歸并存儲(chǔ)高文本自相關(guān)性強(qiáng)LZMA壓縮率優(yōu)勢(shì)明顯盤錢省不少數(shù)據(jù)庫(kù)備份快照高一次性壓縮長(zhǎng)期保存壓縮率直接決定存儲(chǔ)費(fèi)用游戲資源包熱更中依賴解壓速度LZMA解壓還行但內(nèi)存開銷要注意實(shí)時(shí)網(wǎng)絡(luò)傳輸壓縮低CPU占用太高延遲容易失控建議zstd/deflate嵌入式MCU受限環(huán)境低字典內(nèi)存動(dòng)輒幾十MB很多單片機(jī)根本扛不住超高頻寫入的KV系統(tǒng)低壓縮成本會(huì)讓寫入P99成倍惡化從我自己的經(jīng)驗(yàn)看LZMA最舒服的位置在于“一次壓縮、多次讀取”尤其是資源包、固件這類再也不變更的數(shù)據(jù)。反之凡是要求毫秒級(jí)壓縮響應(yīng)、或者寫入路徑吞吐極高的系統(tǒng)我會(huì)第一時(shí)間排除LZMA轉(zhuǎn)而選用zstd這種更懂的平衡的算法。3. 參數(shù)細(xì)節(jié)拆解該動(dòng)哪些、不該動(dòng)哪些3.1 level到底代表什么別只盯著0到9很多庫(kù)都提供了類似“壓縮級(jí)別”的參數(shù)LZMA也不例外。7-Zip SDK里的LzmaCompress接口通過level指定壓縮力度最樸素的理解是level越大壓縮率越高、速度越慢。但底層實(shí)際發(fā)生的變化涉及三塊字典大小、匹配查找器match finder、以及搜索深度。比如level 1默認(rèn)用256KB字典匹配查找器是HC3level 9默認(rèn)用64MB字典匹配查找器是BT4。這些參數(shù)直接決定了壓縮內(nèi)存和壓縮耗時(shí)。實(shí)際項(xiàng)目中我很少直接把level拉滿。原因很簡(jiǎn)單level 9的壓縮率比level 8高不了幾個(gè)百分點(diǎn)耗時(shí)卻往往翻倍。從工程平衡性來(lái)說(shuō)多數(shù)歸檔場(chǎng)景用level 7到8最劃算。而如果你的產(chǎn)物要分發(fā)到內(nèi)存受限的設(shè)備上解壓level反而沒那么關(guān)鍵——解壓內(nèi)存主要取決于解壓方設(shè)置的最大字典上限而不是壓縮時(shí)用的level。這里提個(gè)醒LZMA的編碼器和解碼器對(duì)字典大小有隱式對(duì)齊要求編碼端用的字典如果超過了解碼端允許的最大值解碼器會(huì)直接拒絕或者崩潰。所以在分發(fā)場(chǎng)景里你一定要在壓縮時(shí)明確指定字典上限而不是默認(rèn)隨level走。3.2 lc、lp和pb三個(gè)屬性到底改變了什么這三個(gè)參數(shù)是大伙最頭疼的。lc是字面量上下文位數(shù)lp是字面量位置位數(shù)pb是位置位數(shù)。它們的組合決定了上下文模型怎么區(qū)分“當(dāng)前字節(jié)該用哪一棵概率樹”。默認(rèn)值是lc3、lp0、pb2適用范圍很廣。我簡(jiǎn)單說(shuō)說(shuō)每個(gè)的作用lc建?！扒耙粋€(gè)字是什么”對(duì)預(yù)測(cè)當(dāng)前字的影響。文本類的數(shù)據(jù)增大lc往往有收益但也更吃CPU。lp建?！爱?dāng)前處于什么對(duì)齊位置”對(duì)預(yù)測(cè)的影響。二進(jìn)制結(jié)構(gòu)數(shù)據(jù)比如4字節(jié)對(duì)齊的結(jié)構(gòu)體里增大lp有時(shí)會(huì)帶來(lái)驚喜。pb建?！熬嚯x上一個(gè)匹配多遠(yuǎn)的位置”對(duì)預(yù)測(cè)的影響。這個(gè)值越高匹配距離的建模粒度越細(xì)。三者的總合法范圍是lc lp ≤ 4pb ≤ 4。超出這個(gè)限制編碼器直接就報(bào)參數(shù)錯(cuò)誤。大多數(shù)情況下我建議你直接用默認(rèn)值除非你帶著“內(nèi)存受限但壓縮率還要過一條線”的目標(biāo)去調(diào)。比如某次做嵌入式配置包我把lc從3調(diào)到4pb保持2發(fā)現(xiàn)配置類數(shù)據(jù)的壓縮率立刻好了3%不到但解碼內(nèi)存占用略微上升?？傮w收益不明顯所以后來(lái)我還是回到了默認(rèn)。3.3 字典大小壓縮內(nèi)存與壓縮率的根本交易字典大小dictSize是LZMA最核心的內(nèi)存參數(shù)。編碼端為了讓最多重復(fù)數(shù)據(jù)被匹配需要維護(hù)一個(gè)hash鏈表和查找結(jié)構(gòu)這個(gè)結(jié)構(gòu)的大小通常是字典大小的數(shù)倍?？?-Zip SDK源碼的話LzFind.c里那個(gè)hash表的分配就能看出來(lái)內(nèi)存大頭主要花在hash table和bt tree的節(jié)點(diǎn)分配上。實(shí)際經(jīng)驗(yàn)值編碼端內(nèi)存是字典大小的5到10倍64MB字典意味著編碼內(nèi)存可能沖上300MB以上。解壓端又要小得多因?yàn)長(zhǎng)ZMA解壓只需要維護(hù)一個(gè)字典循環(huán)緩沖區(qū)其大小就是字典上限。這也正是LZMA適合“打包一次、多端解壓”的重要原因?？扇绻阍趬嚎s時(shí)用了64MB字典但在目標(biāo)設(shè)備上把解壓緩沖限制成16MB那解壓直接就失敗。解決方案有兩種壓縮端主動(dòng)把字典調(diào)低或者解壓端按壓縮頭里的數(shù)值自適應(yīng)分配。我個(gè)人的習(xí)慣是給PC客戶端分發(fā)時(shí)字典上限給16MB到32MB給手機(jī)App資源熱更時(shí)壓到8MB老一點(diǎn)的低端Android設(shè)備我甚至?xí)旱?MB。壓縮率會(huì)損失一些但換來(lái)的是所有目標(biāo)機(jī)器都能穩(wěn)解這是值得的。實(shí)踐心得參數(shù)表的含義在官方SDK的LzmaEnc.c里面都有注釋但千萬(wàn)不要照搬示例里的“預(yù)估解壓內(nèi)存dictSize 一些余量”真實(shí)的嵌入式環(huán)境建議自己壓一個(gè)上限數(shù)據(jù)做壓力測(cè)試。4. 實(shí)操落地從壓縮到解壓的完整閉環(huán)4.1 語(yǔ)言與庫(kù)選型你可以從哪里起步動(dòng)手階段先解決“用什么庫(kù)”的問題。這里分語(yǔ)言說(shuō)因?yàn)楹芏嗳藭?huì)被SDK風(fēng)格勸退C/C官方7-Zip SDK里的LzmaEnc.c和LzmaDec.c是最原始、最純正的實(shí)現(xiàn)直接拿源碼編進(jìn)工程就行。缺點(diǎn)是API風(fēng)格老派、錯(cuò)誤碼不夠直觀。LzmaUtil.c這個(gè)示例工程是很好的學(xué)習(xí)起點(diǎn)。Python直接使用標(biāo)準(zhǔn)庫(kù)lzma模塊即可。這對(duì)于快速驗(yàn)證、自動(dòng)化腳本、車載數(shù)據(jù)處理都非常方便不需要安裝任何第三方依賴。pickle序列化后的對(duì)象也可以直接用lzma壓縮保存省事。Java/Kotlin有一個(gè)叫xz的開源庫(kù)它在Java生態(tài)里很常見支持LZMA1、LZMA2和.xz容器。Android端集成也不難。Go官方標(biāo)準(zhǔn)庫(kù)不支持LZMA需要引入第三方庫(kù)實(shí)現(xiàn)常見的方案里性能一般瓶頸在純Go實(shí)現(xiàn)。如果你想在項(xiàng)目里快速出活我的建議流程是先用Python把數(shù)據(jù)和參數(shù)跑通確認(rèn)壓縮率符合預(yù)期再遷移到C/C或者目標(biāo)語(yǔ)言做生產(chǎn)級(jí)實(shí)現(xiàn)。這樣能避免一上來(lái)就陷進(jìn)C API的參數(shù)設(shè)置和內(nèi)存管理里出不來(lái)。4.2 Python快速實(shí)踐十分鐘跑通壓縮解壓Python的lzma模塊之所以好用是因?yàn)樗押芏嗉?xì)節(jié)都封裝好了。下面這段代碼是我常用的最小模板兼顧了壓縮、解壓和參數(shù)控制import lzma import os # 壓縮 data b這是一段用于測(cè)試LZMA壓縮的文本數(shù)據(jù)。 * 10000 compressed lzma.compress( data, formatlzma.FORMAT_ALONE, # 裸LZMA流不是.xz容器 filters[{ id: lzma.FILTER_LZMA1, preset: 7, # 壓縮預(yù)設(shè)等級(jí) dict_size: 1 26, # 64MB字典注意內(nèi)存 lc: 3, lp: 0, pb: 2, }], ) print(f原始大小: {len(data)}) print(f壓縮后大小: {len(compressed)}) print(f壓縮率: {len(compressed) / len(data) * 100:.2f}%) # 解壓 decompressed lzma.decompress( compressed, formatlzma.FORMAT_ALONE, ) assert decompressed data, 數(shù)據(jù)不一致 print(解壓成功數(shù)據(jù)完全一致)這里有個(gè)非常關(guān)鍵的點(diǎn)FORMAT_ALONE對(duì)應(yīng)的是裸LZMA流默認(rèn)的FORMAT_XZ對(duì)應(yīng)的是.xz容器。如果壓縮用ALONE、解壓用默認(rèn)的FORMAT_XZ會(huì)直接拋錯(cuò)。另外preset和dict_size同時(shí)指定時(shí)dict_size會(huì)覆蓋預(yù)設(shè)里的默認(rèn)字典這是精確控制資源占用的好辦法。如果你不想手動(dòng)配filters直接lzma.compress(data, preset9)也行但此時(shí)你無(wú)法控制字典上限內(nèi)存占用不受你把控。線上服務(wù)里我?guī)缀醵际菐е鴉ilters參數(shù)顯式指定目的就是避免某次代碼調(diào)整把壓縮任務(wù)的內(nèi)存打到2GB。4.3 C接口核心流程別被LzmaCompress的參數(shù)嚇到切換到C/C時(shí)主要API是LzmaCompress和LzmaUncompress。前者位于LzmaLib.h里函數(shù)簽名挺長(zhǎng)核心調(diào)用方式如下#include stdio.h #include string.h #include LzmaLib.h #define IN_BUF_SIZE (1 20) #define OUT_BUF_SIZE (1 20) int main(void) { // 原始數(shù)據(jù)實(shí)際項(xiàng)目中從文件或網(wǎng)絡(luò)讀取 unsigned char in_data[IN_BUF_SIZE]; memset(in_data, A, sizeof(in_data)); // 準(zhǔn)備壓縮輸出緩沖區(qū) unsigned char out_props[5]; size_t out_props_size sizeof(out_props); unsigned char *out_data malloc(IN_BUF_SIZE IN_BUF_SIZE / 3 128); size_t out_data_size malloc_usable_size(out_data); if (!out_data) return -1; int level 7; unsigned dict_size 1 24; // 16MB int lc 3, lp 0, pb 2; unsigned fb 273; int algo 1; // 0fast, 1normal unsigned bt_mode 1; int ret LzmaCompress( out_data, out_data_size, in_data, sizeof(in_data), out_props, out_props_size, level, dict_size, lc, lp, pb, fb, algo, bt_mode ); if (ret ! SZ_OK) { fprintf(stderr, 壓縮失敗錯(cuò)誤碼: %d\n, ret); free(out_data); return -1; } printf(壓縮后大小: %zu bytes\n, out_data_size); free(out_data); return 0; }這段代碼自動(dòng)選擇壓縮級(jí)別但它引出了另一個(gè)問題C接口解壓時(shí)怎么知道壓縮流屬性答案是先讀那5個(gè)字節(jié)的out_props。解碼端拿到這5個(gè)字節(jié)后傳入LzmaUncompress才能正確初始化解壓狀態(tài)。裸LZMA流的5字節(jié)屬性中第0字節(jié)是(lc, lp, pb)的打包結(jié)果后4字節(jié)是小端序的字典大小。這個(gè)結(jié)構(gòu)極其重要但也極其容易出錯(cuò)。我的經(jīng)驗(yàn)是在上層協(xié)議里把這5字節(jié)和8字節(jié)的解壓大小作為自定義頭部一并存儲(chǔ)或傳輸。比如做成一個(gè)24字節(jié)的文件頭5字節(jié)屬性、8字節(jié)原始大小、4字節(jié)文件名長(zhǎng)度、剩余是文件名和壓縮數(shù)據(jù)。這樣解壓端不需要額外約定就能完成精確的動(dòng)態(tài)分配和狀態(tài)初始化。4.4 使用.xz容器時(shí)的流式處理生產(chǎn)環(huán)境里數(shù)據(jù)往往不可能一次性全部載入內(nèi)存這時(shí)候“流式編碼/解碼”就派上用場(chǎng)了。Python的lzma模塊對(duì).xz容器支持得很順手配合LZMAFile可以一邊讀一邊寫內(nèi)存始終維持低位import lzma # 流式壓縮邊讀邊寫 with open(large.bin, rb) as fin, lzma.open(large.bin.xz, wb, preset7) as fout: while True: chunk fin.read(1 20) # 每次處理1MB if not chunk: break fout.write(chunk) # 流式解壓邊讀邊還原 with lzma.open(large.bin.xz, rb) as fin, open(restored.bin, wb) as fout: while True: chunk fin.read(1 20) if not chunk: break fout.write(chunk)但請(qǐng)注意裸LZMA流不支持這種流式操作因?yàn)長(zhǎng)ZMA編碼器必須持續(xù)維護(hù)上下文產(chǎn)生的是“有狀態(tài)”的連續(xù)字節(jié)流——拿Python的lzma.decompress去處理裸流時(shí)通常仍然是整塊整塊喂進(jìn)去。如果你確實(shí)需要流式處理而且不想要.xz容器另一種思路是把大文件拆成多塊各自獨(dú)立做裸LZMA壓縮然后給每塊加上索引頭。這個(gè)方案的優(yōu)點(diǎn)是解壓端可以進(jìn)行隨機(jī)訪問缺點(diǎn)是壓縮率因?yàn)榍袎K而有所下降。切塊大小我常用4MB到16MB損耗通常在5%以內(nèi)。5. 高頻踩坑與排查經(jīng)驗(yàn)都是實(shí)測(cè)過才敢寫5.1 編碼屬性不一致解壓端直接拒絕這可能是最頻繁的現(xiàn)場(chǎng)事故?，F(xiàn)象是壓縮端用某個(gè)字典、lc/lp/pb組合壓縮解壓時(shí)如果屬性值不匹配LzmaUncompress會(huì)報(bào)錯(cuò)或者更糟——不報(bào)錯(cuò)卻輸出一堆錯(cuò)亂數(shù)據(jù)。裸LZMA之所以要把5字節(jié)屬性放在最前面就是讓解碼端按屬性初始化?？梢坏┯腥藞D省事把屬性硬編碼成固定值數(shù)據(jù)流一變就翻車。我在一個(gè)模擬項(xiàng)目X里就碰到過模塊A用默認(rèn)屬性壓縮模塊B解壓時(shí)把屬性寫死了結(jié)果版本升級(jí)后壓縮端換了字典大小線上解壓率瞬間變成100%失敗。修法也不復(fù)雜——解壓端嚴(yán)格讀取流里的屬性字節(jié)而不是自己猜。5.2 解壓輸出緩沖大小別拿壓縮后大小當(dāng)解壓大小裸LZMA編碼頭里那8字節(jié)的uncompressed size作用是告訴解壓端“總共要解多大”。但很多文檔說(shuō)這個(gè)值可以為0表示未知。一旦為0LzmaUncompress就沒了目標(biāo)長(zhǎng)度參照必須靠循環(huán)反復(fù)喂數(shù)據(jù)。在這個(gè)模式下解壓端要特別注意輸出緩沖的擴(kuò)容邏輯否則會(huì)不斷遇到SZ_ERROR_OUTPUT_EOF。我的建議無(wú)論使用什么語(yǔ)言都盡量在壓縮頭里保留真實(shí)的原始大小。巧的是LZMA SDK需要在壓縮前就把原始大小傳進(jìn)去所以“流式壓縮且不知道原始大小”本身就是個(gè)矛盾場(chǎng)景。通常的工程化解法是先寫入一個(gè)臨時(shí)文件或者先在內(nèi)存里匯總再回頭填大小字段。5.3 多線程壓縮遠(yuǎn)沒有想象的那么美LZMA對(duì)每個(gè)獨(dú)立的數(shù)據(jù)塊進(jìn)行壓縮時(shí)是可以并行的LZMA2就支持分塊獨(dú)立編碼因此天然適合多線程。但如果你用的是裸LZMA它是一條有狀態(tài)的連續(xù)流只有單線程實(shí)現(xiàn)。很多人在服務(wù)端想用裸LZMA壓縮大文件發(fā)現(xiàn)CPU只有一個(gè)核在跑這就是本質(zhì)原因。所以要做并行壓縮請(qǐng)優(yōu)先用LZMA2或直接切成多塊獨(dú)立壓縮。用Python時(shí)最簡(jiǎn)單的并行方案如下import lzma from concurrent.futures import ThreadPoolExecutor def compress_chunk(chunk): return lzma.compress(chunk, formatlzma.FORMAT_XZ, preset6) chunks [block_0, block_1, block_2] with ThreadPoolExecutor(max_workers4) as pool: compressed_chunks list(pool.map(compress_chunk, chunks))但這里要權(quán)衡切塊越小塊與塊之間的歷史參考越少壓縮率下降越多。切塊越大并行度越低。我用過的穩(wěn)妥方案是單塊1MB到4MB四線程并行壓縮率損失能控制在3%到6%之間同時(shí)吞吐能提升三倍以上。5.4 解壓失敗“數(shù)據(jù)損壞”的真兇內(nèi)存碎塊C接口下高頻次壓縮小數(shù)據(jù)時(shí)即便邏輯看起來(lái)完全正確也偶爾會(huì)偶發(fā)SZ_ERROR_DATA錯(cuò)誤。排查了很久我才明白問題出在SDK使用了一個(gè)自定義內(nèi)存分配器它默認(rèn)依賴系統(tǒng)malloc但要求緩沖區(qū)對(duì)齊。當(dāng)整個(gè)系統(tǒng)長(zhǎng)時(shí)間運(yùn)行、內(nèi)存碎片嚴(yán)重時(shí)分配器拿到的內(nèi)存塊邊界可能不理想導(dǎo)致區(qū)間編碼器的讀寫出問題。這不是算法本身的問題而是工程集成的問題。修法有兩個(gè)方向一是改用SDK自帶的Alloc和Free函數(shù)指針注入穩(wěn)定的內(nèi)存池二是干脆把單次分配大小固定下來(lái)避免頻繁變長(zhǎng)分配。我親手經(jīng)歷過某設(shè)備上報(bào)的偶發(fā)解壓失敗就是在統(tǒng)一了分配器策略之后徹底消失的。5.5 進(jìn)度條到底應(yīng)該怎么算壓縮任務(wù)的進(jìn)度好算因?yàn)榫幋a端知道讀了多少輸入、寫了多少輸出。解壓進(jìn)度是玄學(xué)——尤其是裸LZMA雖然頭里有8字節(jié)的原始大小但在解壓完成前你無(wú)法知道當(dāng)前輸出相對(duì)于最終大小的準(zhǔn)確比例因?yàn)閰^(qū)間解碼器必須把所有的bit都消費(fèi)完才知道準(zhǔn)確位置。實(shí)際中我做進(jìn)度條采用的是“塊級(jí)百分比”如果數(shù)據(jù)被設(shè)計(jì)成多塊獨(dú)立壓縮結(jié)構(gòu)每解完一個(gè)塊就按塊比例更新進(jìn)度。如果是單條LZMA流那就只能拿“已解壓字節(jié)數(shù) / 頭部聲明的原始大小”估算。后者在某種程度上是準(zhǔn)的但由于LZMA解碼器輸出和輸入之間存在緩沖窗尾部會(huì)有幾KB的滯后顯示。5.6 字典過大導(dǎo)致內(nèi)存申請(qǐng)失敗這件事在32位進(jìn)程和嵌入式平臺(tái)上尤其常見。某次我在老設(shè)備上集成LZMA解壓壓縮端發(fā)來(lái)一個(gè)64MB字典的流解碼端按規(guī)定申請(qǐng)了64MB緩沖加上系統(tǒng)其他模塊的內(nèi)存開銷直接觸發(fā)OOM。現(xiàn)象是解壓到一半進(jìn)程被殺沒有任何錯(cuò)誤日志。這給我們的教訓(xùn)是在分布式或跨設(shè)備傳輸數(shù)據(jù)的項(xiàng)目里解壓上限永遠(yuǎn)是參與方共同約定的協(xié)議字段。壓縮方不能只考慮自己的性能必須知道對(duì)端能承受的最大字典是多少。我經(jīng)常做的一個(gè)動(dòng)作就是在壓縮參數(shù)前加一道“目標(biāo)能力校驗(yàn)”把字典上限作為一個(gè)配置文件下發(fā)到編碼端禁止本地隨意改大。6. 進(jìn)階玩法把LZMA揉進(jìn)你的業(yè)務(wù)架構(gòu)6.1 隨機(jī)訪問壓縮包分塊裸流索引表如果你要壓縮一個(gè)很大的數(shù)據(jù)集又希望解壓端能直接讀取中間某一段而不是從頭解到尾可以考慮“分塊裸流外部索引”的結(jié)構(gòu)。也就是把數(shù)據(jù)按固定大小切塊逐個(gè)裸LZMA壓縮每塊頭部記錄塊號(hào)、原始偏移、壓縮偏移、壓縮后大小。讀取時(shí)根據(jù)目標(biāo)偏移定位塊號(hào)只解壓那一塊。這種方案的壓縮率比整體壓縮低一些但數(shù)據(jù)中心場(chǎng)景里的收益非常大。我做過一個(gè)模擬數(shù)據(jù)倉(cāng)庫(kù)原先查詢某個(gè)字段要解壓整個(gè)300MB的包耗時(shí)十幾秒改成分塊之后定位到目標(biāo)塊只要幾百毫秒體驗(yàn)完全是兩碼事。切塊大小我通常按“單塊原始數(shù)據(jù)4MB、壓縮后約1到2MB”來(lái)設(shè)太大失去隨機(jī)訪問意義太小會(huì)讓索引表膨脹。6.2 對(duì)加密數(shù)據(jù)做壓縮順序別搞反“先加密還是先壓縮”是每個(gè)架構(gòu)師都要回答的問題。如果你是先加密再壓縮加密后的字節(jié)流近似均勻隨機(jī)LZMA根本找不到冗余壓縮率接近無(wú)。正確的姿勢(shì)是先壓縮后加密。這讓壓縮算法能盡可能多地消除數(shù)據(jù)冗余然后再交給加密層去保證機(jī)密性。但這里有一個(gè)現(xiàn)實(shí)悖論如果原始數(shù)據(jù)本身就是強(qiáng)隨機(jī)的比如已經(jīng)是加密后的數(shù)據(jù)LZMA壓了幾乎等于沒壓反而白白消耗CPU。所以業(yè)務(wù)上一定要分類壓縮層只處理那些“明文里包含可壓縮冗余”的數(shù)據(jù)。如果某些字段是密文那直接跳過壓縮環(huán)節(jié)省掉無(wú)意義的CPU和時(shí)間開銷。6.3 使用LZMA做協(xié)議級(jí)壓縮時(shí)的“包大小”陷阱在RPC或者消息隊(duì)列里用LZMA壓縮小包經(jīng)常會(huì)出現(xiàn)“越壓越大”的現(xiàn)象。原因是LZMA有概率模型初始化的固定開銷對(duì)于小于幾百字節(jié)的數(shù)據(jù)模型還沒來(lái)得及建立優(yōu)勢(shì)就已經(jīng)結(jié)束了。這類場(chǎng)景下壓縮后體積很可能超過原始數(shù)據(jù)。我一般會(huì)設(shè)一個(gè)閾值原始包小于2KB時(shí)直接透?jìng)鞔笥?KB才嘗試壓縮。這個(gè)閾值對(duì)LZMA特別重要因?yàn)樗皇堑脱舆t算法。真實(shí)項(xiàng)目里有一次我看到某個(gè)消息網(wǎng)關(guān)在錯(cuò)誤地壓縮100字節(jié)左右的JSON包結(jié)果平均每條多出了80字節(jié)帶寬白白多耗了。加了閾值和最小收益判斷之后整體流量立刻回落。6.4 選擇.xz還是裸LZMA別為了“輕量”犧牲兼容性雖然裸LZMA流的封裝非常小只帶5字節(jié)屬性8字節(jié)大小很多人會(huì)覺得比.xz更省、更簡(jiǎn)單。但裸LZMA有兩個(gè)致命缺點(diǎn)沒有校驗(yàn)和、不支持流式并行。如果數(shù)據(jù)在傳輸或者存儲(chǔ)過程中損壞了一個(gè)bit編碼器無(wú)法自檢解壓時(shí)要么產(chǎn)生靜默錯(cuò)誤數(shù)據(jù)要么直接報(bào)錯(cuò)。而.xz容器自帶CRC64校驗(yàn)?zāi)軌蚋兄獡p壞并報(bào)錯(cuò)。所以我強(qiáng)烈建議凡是跑在有不可靠鏈路或者長(zhǎng)期存儲(chǔ)的設(shè)備上優(yōu)先選擇.xz容器格式。只有當(dāng)你需要極致最小的元數(shù)據(jù)、且上層協(xié)議已經(jīng)自帶校驗(yàn)時(shí)才考慮裸流。如果不是因?yàn)槟承├鲜紹ootloader只認(rèn)裸LZMA我可能根本不在生產(chǎn)項(xiàng)目里用裸流。7. 性能調(diào)優(yōu)把LZMA壓出最佳性價(jià)比7.1 壓縮級(jí)別選擇別迷信9很多人覺得壓縮率“越高越好”但LZMA的壓縮時(shí)間和壓縮率曲線并不是理想線性關(guān)系?；谀硞€(gè)20MB的混合數(shù)據(jù)測(cè)試得到一組典型數(shù)據(jù)如下配置壓縮時(shí)長(zhǎng)(秒)壓縮后大小(MB)說(shuō)明level 11.111.8適合臨時(shí)場(chǎng)景或極低內(nèi)存level 31.910.7性價(jià)比尚可level 52.810.1日常推薦level 75.29.4歸檔推薦level 911.79.1壓縮率提升極有限從7級(jí)升到9級(jí)壓縮率只好了3%左右耗時(shí)卻翻了約一倍。對(duì)于大多數(shù)業(yè)務(wù)歸檔用7到8級(jí)就夠了。如果服務(wù)器的CPU比較緊張用5級(jí)和7級(jí)的差距也不到10%但耗時(shí)差距明顯。壓縮率固然重要工程上始終要算總賬。7.2 字典大小的調(diào)優(yōu)路徑字典大小調(diào)整的核心思想是讓字典覆蓋數(shù)據(jù)的“局部重復(fù)跨度”。如果數(shù)據(jù)里最長(zhǎng)重復(fù)段只有幾KB那么1MB字典和64MB字典壓縮率幾乎相同后者只會(huì)白白浪費(fèi)內(nèi)存。如果你不確定可以按十倍經(jīng)驗(yàn)去試先用1MB再試4MB、16MB。觀察壓縮率的邊際收益一旦收益趨緩就停止增大。有一個(gè)更容易操作的方法是做一個(gè)“壓縮率-字典大小”的階梯測(cè)試腳本輸入真實(shí)樣本自動(dòng)輸出每次的壓縮率和耗時(shí)。我保留著這套小工具每次接新項(xiàng)目時(shí)都用它快速定基準(zhǔn)。它的實(shí)現(xiàn)非常簡(jiǎn)單核心就是用循環(huán)調(diào)用不同dict_size的compress然后打印結(jié)果。數(shù)據(jù)樣本最好用線上真實(shí)數(shù)據(jù)里抽樣拼接出來(lái)的不要用假數(shù)據(jù)否則你會(huì)得到一個(gè)完全沒有參考價(jià)值的曲線。7.3 解壓性能往往被忽視真正影響線上體驗(yàn)的是解壓速度。LZMA解壓速度大約在40MB/s到80MB/s的數(shù)量級(jí)視數(shù)據(jù)和CPU而定比gzip、zstd低不少。如果業(yè)務(wù)要求高頻讀取壓縮后的文件那么你優(yōu)化壓縮率收益也要同時(shí)接受解壓變慢的現(xiàn)實(shí)。我做過一個(gè)實(shí)驗(yàn)一個(gè)400MB的文本歸檔文件用LZMA壓縮成120MB解壓耗時(shí)6秒。換成zstd壓縮成160MB解壓只花1.5秒。如果這個(gè)文件每次服務(wù)啟動(dòng)都要加載一次那多出來(lái)的4.5秒就會(huì)直接出現(xiàn)在啟動(dòng)時(shí)間上。所以大型服務(wù)的配置文件、模型文件我更傾向于用zstd而不是LZMA換取更快的加載速度。8. 一點(diǎn)個(gè)人心得LZMA這套算法從1998年出現(xiàn)在7-Zip里到現(xiàn)在已經(jīng)二十多年但它在工程界的地位依然非常穩(wěn)。它不是用來(lái)解決所有數(shù)據(jù)的通用銀彈而是一個(gè)“在最大壓縮率和資源消耗之間需要深刻權(quán)衡”的專用工具。我對(duì)LZMA的總體印象是極端的壓縮率來(lái)自它對(duì)數(shù)據(jù)概率的極致建模這也意味著它不能像gzip那樣被無(wú)腦使用。真正穩(wěn)妥的做法始終是先理解數(shù)據(jù)特性、再明確資源邊界、最后選擇合適的封裝和參數(shù)。最后分享一個(gè)小技巧在團(tuán)隊(duì)內(nèi)部推廣LZMA方案時(shí)別只丟出一句“壓縮率好”最好做一個(gè)針對(duì)實(shí)際數(shù)據(jù)的對(duì)比表格把壓縮率、耗時(shí)、內(nèi)存峰值都列出來(lái)。多數(shù)情況下決定用不用LZMA的不是算法本身而是團(tuán)隊(duì)愿不愿意為那多出來(lái)的幾個(gè)百分點(diǎn)去增加資源開銷。數(shù)據(jù)說(shuō)話永遠(yuǎn)最有說(shuō)服力。