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