1. 項(xiàng)目起底caveman到底在解決什么問(wèn)題1.1 為什么叫cavemancaveman不是一個(gè)復(fù)古游戲也不是什么部落生存App這是我維護(hù)了大半年的一個(gè)命令行工具項(xiàng)目。名字聽(tīng)起來(lái)確實(shí)像穴居人核心思路也刻意走原始路線用標(biāo)準(zhǔn)C寫(xiě)一個(gè)零第三方依賴的日志解析與指標(biāo)聚合程序編譯出來(lái)只有一個(gè)可執(zhí)行文件扔到幾十臺(tái)只裝了最小化系統(tǒng)的老服務(wù)器上也能直接跑。最初觸發(fā)這個(gè)項(xiàng)目的是很現(xiàn)實(shí)的問(wèn)題。團(tuán)隊(duì)里有一套Python寫(xiě)的日志統(tǒng)計(jì)腳本看起來(lái)功能挺全但每次部署都像渡劫有的機(jī)器Python版本不對(duì)有的機(jī)器缺pip包有的機(jī)器因?yàn)榘踩呗圆蛔屇懵?lián)網(wǎng)裝東西。更麻煩的是腳本一跑就是兩三個(gè)小時(shí)中途內(nèi)存漲到2GB多經(jīng)常被OOM Killer干掉。我那時(shí)候就想到底有沒(méi)有一種方式能讓這種工具像cp、grep一樣拷過(guò)去就能用跑起來(lái)還不容易死。那次排查持續(xù)了一周最后我干脆決定自己動(dòng)手。既然要避開(kāi)解釋器、運(yùn)行時(shí)和包管理這些麻煩最直接的選擇就是C語(yǔ)言。于是caveman這個(gè)項(xiàng)目就誕生了目標(biāo)非常簡(jiǎn)單一個(gè)二進(jìn)制處理完輸入就退出內(nèi)存占用可預(yù)測(cè)速度盡量快出錯(cuò)時(shí)能夠給出明確提示而不會(huì)整機(jī)崩潰。1.2 需求清單的確認(rèn)任何項(xiàng)目動(dòng)手之前需求不敲定后面一定會(huì)反復(fù)返工。caveman的第一版需求清單其實(shí)很短但每條都是從實(shí)際痛點(diǎn)里提煉出來(lái)的需求說(shuō)明優(yōu)先級(jí)單一可執(zhí)行文件拷貝即用不依賴任何外部運(yùn)行時(shí)和動(dòng)態(tài)庫(kù)極高啟動(dòng)速度快冷啟動(dòng)到開(kāi)始處理數(shù)據(jù)不超過(guò)50ms高內(nèi)存可控處理1GB文件時(shí)峰值內(nèi)存不超過(guò)200MB高支持管道處理能從stdin讀入也能直接處理文件列表高輸出格式穩(wěn)定支持CSV和JSON兩種輸出方便下游腳本消費(fèi)中錯(cuò)誤可診斷任何異常都能定位到具體的行號(hào)和狀態(tài)中這份清單看著簡(jiǎn)單但后來(lái)每次做技術(shù)取舍我都會(huì)回頭對(duì)照它。要不要引入第三方解析庫(kù)不會(huì)破壞單一可執(zhí)行文件的需求。要不要用多線程并行處理暫緩因?yàn)槎嗑€程會(huì)把內(nèi)存峰值和調(diào)試成本都拉高。要不要支持復(fù)雜的表達(dá)式過(guò)濾不加那會(huì)模糊項(xiàng)目的邊界。定下需求之后整體方向就清晰了。這個(gè)工具的核心是一個(gè)狀態(tài)機(jī)驅(qū)動(dòng)的流式解析器外加一個(gè)簡(jiǎn)單但夠用的哈希表做聚合統(tǒng)計(jì)最后按固定格式輸出。整個(gè)過(guò)程不需要把整個(gè)文件讀進(jìn)內(nèi)存而是采用固定緩沖區(qū)的流式讀取逐塊處理逐行聚合。1.3 適用對(duì)象與場(chǎng)景caveman適合誰(shuí)首先是天天跟日志、文本記錄打交道的運(yùn)維和后端開(kāi)發(fā)者。比如你需要統(tǒng)計(jì)一天之內(nèi)某個(gè)業(yè)務(wù)接口的調(diào)用次數(shù)、異常碼分布、響應(yīng)耗時(shí)分位數(shù)但手頭只有一個(gè)解壓后的原始日志又不想費(fèi)勁去搭大數(shù)據(jù)平臺(tái)這種場(chǎng)景就很適合。其次它適合所有對(duì)部署環(huán)境有嚴(yán)格限制的場(chǎng)景。我已經(jīng)不止一次碰到客戶機(jī)器不允許安裝任何額外軟件包的情況甚至不保證有Python環(huán)境。這種時(shí)候一個(gè)編譯好的caveman可執(zhí)行文件比什么都好用直接scp上去就能跑跑完把結(jié)果拿回來(lái)機(jī)器上不留任何痕跡。如果你是一個(gè)對(duì)新工具持有好奇心愿意自己動(dòng)手折騰的人也可以把它當(dāng)作一個(gè)學(xué)習(xí)案例。后面我會(huì)講到手寫(xiě)狀態(tài)機(jī)解析、內(nèi)存池設(shè)計(jì)、哈希表沖突處理這些偏底層的細(xì)節(jié)思路可以遷移到很多其他語(yǔ)言的項(xiàng)目里。2. 整體設(shè)計(jì)與架構(gòu)決策2.1 技術(shù)選型為什么是C而不是Go或Rust決定用C語(yǔ)言不是因?yàn)槲移珢?ài)C而是這個(gè)項(xiàng)目的需求恰好把C的劣勢(shì)都規(guī)避了又把C的優(yōu)勢(shì)發(fā)揮到極致。先說(shuō)說(shuō)為什么不用Go。Go的部署確實(shí)方便交叉編譯也是加分項(xiàng)但Go二進(jìn)制里塞了運(yùn)行時(shí)體積隨隨便便就上10MB。在追求“盡可能小”的場(chǎng)景里這多出來(lái)的體積不算致命可還有另外一個(gè)問(wèn)題Go的GC會(huì)帶來(lái)不確定的停頓雖然通常影響不大但在處理超大日志時(shí)觀察過(guò)幾次內(nèi)存翻倍和GC暫停和我“內(nèi)存可控”的目標(biāo)有點(diǎn)沖突。Rust其實(shí)是不錯(cuò)的選擇內(nèi)存安全、性能接近C而且cargo管理依賴很舒服。但Rust對(duì)編譯工具鏈的要求不低很多老服務(wù)器上的gcc版本不行rustup安裝又受網(wǎng)絡(luò)限制。做運(yùn)維工具的人都有個(gè)習(xí)慣能用現(xiàn)有環(huán)境輕松編譯的就選現(xiàn)有的不要為了一時(shí)舒服制造部署負(fù)擔(dān)。C語(yǔ)言就是那個(gè)“在任何一個(gè)機(jī)器上都大概率能編譯”的語(yǔ)言。標(biāo)準(zhǔn)C11加上POSIX接口只依賴libc和內(nèi)核編譯選項(xiàng)控制得當(dāng)連動(dòng)態(tài)庫(kù)都可以不依賴。在嵌入式、容器、最小化Linux系統(tǒng)這些場(chǎng)景里C幾乎是唯一一個(gè)不太需要擔(dān)心“環(huán)境沒(méi)有它就跑不了”的語(yǔ)言。當(dāng)然選C等于把內(nèi)存管理的責(zé)任全部背到自己身上。這個(gè)代價(jià)不能忽視所以我專門(mén)設(shè)計(jì)了內(nèi)存池來(lái)集中管理內(nèi)存分配后面會(huì)詳細(xì)說(shuō)。2.2 模塊劃分與數(shù)據(jù)流caveman的代碼結(jié)構(gòu)刻意做得非常簡(jiǎn)單我不喜歡一個(gè)工具項(xiàng)目一上來(lái)就搞十幾個(gè)目錄。最終劃分成四個(gè)核心模塊main.c入口、命令行參數(shù)解析、頂層流程控制parser.c流式解析器負(fù)責(zé)把文本按行拆開(kāi)并提取字段store.c聚合存儲(chǔ)層負(fù)責(zé)哈希表、內(nèi)存池和統(tǒng)計(jì)值更新report.c輸出層負(fù)責(zé)將結(jié)果寫(xiě)成CSV或JSON這四個(gè)模塊之間只通過(guò)很小的幾個(gè)接口交互。main拿到命令行參數(shù)之后把輸入源統(tǒng)一抽象成一個(gè)“讀取器”。讀取器要么是open后的文件描述符要么直接是stdin解析器不關(guān)心數(shù)據(jù)從哪來(lái)只關(guān)心next()函數(shù)是否還能返回新的一行。這樣的分層帶來(lái)一個(gè)額外的好處測(cè)試的時(shí)候可以把任意一段文本通過(guò)管道喂進(jìn)去不用構(gòu)建復(fù)雜的測(cè)試文件系統(tǒng)。我在單元測(cè)試?yán)锎罅渴褂胑cho加管道的組合比如echo -e a\nb\nc | caveman --format csv測(cè)起來(lái)非常順手。數(shù)據(jù)流的方向是單向的一行文本進(jìn)入parser之后解析出鍵值對(duì)更新到store里。store里的數(shù)據(jù)最終由report讀取并格式化。全程沒(méi)有回調(diào)函數(shù)沒(méi)有復(fù)雜的事件循環(huán)就是一個(gè)簡(jiǎn)單的線性流程。這種設(shè)計(jì)思路可能在一些人眼里過(guò)于樸素但恰恰是這種樸素讓問(wèn)題定位變得特別容易。任何一個(gè)環(huán)節(jié)出問(wèn)題只要追蹤一個(gè)方向就能找到根因。2.3 三個(gè)關(guān)鍵取舍第一個(gè)取舍是不用多線程。日志解析這個(gè)任務(wù)本質(zhì)上是IO密集和簡(jiǎn)單計(jì)算密集的混合體理論上用多線程確實(shí)能提速。但我評(píng)估了一下復(fù)雜度多線程意味著要處理鎖競(jìng)爭(zhēng)、線程池、任務(wù)隊(duì)列還要處理各個(gè)線程統(tǒng)計(jì)結(jié)果的合并。一旦引入這些內(nèi)存峰值會(huì)上去bug排查難度也會(huì)成倍增加。項(xiàng)目初版先跑通性能不夠再做多進(jìn)程也行反正數(shù)據(jù)可以分片。第二個(gè)取舍是不做異步IO。異步IO很時(shí)髦但對(duì)這個(gè)項(xiàng)目來(lái)說(shuō)收益不大。我們用標(biāo)準(zhǔn)read/write配合一個(gè)64KB的緩沖區(qū)在絕大多數(shù)場(chǎng)景下已經(jīng)能吃掉磁盤(pán)的吞吐能力。真要做異步還得考慮不同平臺(tái)的多路復(fù)用機(jī)制差異這明顯違背了零負(fù)擔(dān)部署的初衷。第三個(gè)取舍是內(nèi)存池。C語(yǔ)言里malloc和free本身不慢但頻繁分配小塊內(nèi)存會(huì)出現(xiàn)碎片和性能抖動(dòng)。對(duì)于解析日志這種模式每解析一行就有若干臨時(shí)字符串如果用malloc/free那調(diào)用次數(shù)會(huì)極其夸張。內(nèi)存池的做法是一次性向系統(tǒng)申請(qǐng)一大塊內(nèi)存內(nèi)部用游標(biāo)切分解析過(guò)程中產(chǎn)生的臨時(shí)對(duì)象全部從池子里分配任務(wù)結(jié)束直接把整塊內(nèi)存交還系統(tǒng)。省掉了free的逐個(gè)調(diào)用也避免了碎片的出現(xiàn)。需要強(qiáng)調(diào)一點(diǎn)內(nèi)存池不是所有情況的萬(wàn)能藥。如果每個(gè)對(duì)象生命周期差異很大內(nèi)存池可能會(huì)造成巨大浪費(fèi)。但日志解析的特點(diǎn)是周期短、體量大、生命周期整齊所有臨時(shí)字符串都是活到當(dāng)前行處理完就不用了這正好匹配內(nèi)存池的長(zhǎng)處。3. 實(shí)操過(guò)程從零構(gòu)建caveman核心3.1 工程骨架與構(gòu)建腳本我習(xí)慣新建項(xiàng)目時(shí)先把構(gòu)建腳本寫(xiě)好哪怕是三四個(gè)源文件的小項(xiàng)目也要讓make build和make test能一鍵完成。caveman的目錄結(jié)構(gòu)很簡(jiǎn)單caveman/ ├── src/ │ ├── main.c │ ├── parser.c │ ├── parser.h │ ├── store.c │ ├── store.h │ ├── report.c │ └── report.h ├── tests/ │ ├── run_tests.sh │ └── fixtures/ ├── Makefile └── README.mdMakefile寫(xiě)得也比較克制沒(méi)有用autotools因?yàn)椴幌霝榱艘粋€(gè)單文件工具引入一整套構(gòu)建系統(tǒng)。下面是核心的構(gòu)建規(guī)則我做了個(gè)簡(jiǎn)化版CC ? gcc CFLAGS ? -stdc11 -O2 -Wall -Wextra -fno-strict-aliasing LDFLAGS ? -static BIN : caveman SRC : $(wildcard src/*.c) OBJ : $(SRC:.c.o) all: $(BIN) $(BIN): $(OBJ) $(CC) $(CFLAGS) -o $ $^ $(LDFLAGS) %.o: %.c $(CC) $(CFLAGS) -c -o $ $ test: $(BIN) bash tests/run_tests.sh clean: rm -f $(OBJ) $(BIN)幾個(gè)值得注意的細(xì)節(jié)。第一-fno-strict-aliasing在C語(yǔ)言里基本屬于保險(xiǎn)開(kāi)關(guān)因?yàn)橛行├洗a在指針類型轉(zhuǎn)換上不夠嚴(yán)謹(jǐn)取消嚴(yán)格別名規(guī)則能減少莫名奇妙的優(yōu)化bug。第二-static這個(gè)選項(xiàng)會(huì)把libc靜態(tài)鏈接進(jìn)去生成的文件會(huì)稍微大一點(diǎn)但換來(lái)的是在目標(biāo)機(jī)器上不需要任何動(dòng)態(tài)庫(kù)。對(duì)于caveman這種工具追求的就是極致的可移植性體積多幾百KB完全可以接受。編譯生成的二進(jìn)制在老服務(wù)器上實(shí)測(cè)大概是300KB左右這在今天動(dòng)輒幾十MB的工具里面真的有點(diǎn)特殊的時(shí)代感。但就是這300KB解決了我們長(zhǎng)久以來(lái)的部署難題。3.2 手寫(xiě)狀態(tài)機(jī)解析器解析器是caveman最核心的部分也是最值得說(shuō)的。如果考慮用正則表達(dá)式來(lái)解析日志那寫(xiě)起來(lái)確實(shí)舒服但正則庫(kù)的依賴會(huì)打破零依賴原則而且正則引擎在處理特別長(zhǎng)的行時(shí)存在災(zāi)難性回溯的風(fēng)險(xiǎn)。對(duì)于一個(gè)需要長(zhǎng)時(shí)間穩(wěn)定運(yùn)行的解析工具這種不確定性是不能接受的。所以我把解析器做成一個(gè)確定性的狀態(tài)機(jī)。以解析常見(jiàn)的訪問(wèn)日志為例一條日志長(zhǎng)這樣2025-01-15T10:24:3108:00 [INFO] user10086 api/order/detail code200 cost185ms我們需要提取時(shí)間、用戶ID、接口路徑、狀態(tài)碼和耗時(shí)。狀態(tài)機(jī)的思路是逐字符掃描把整個(gè)解析過(guò)程分為幾個(gè)明確的狀態(tài)STATE_TIME讀取時(shí)間字段遇到空格就切到下一個(gè)字段STATE_LEVEL讀日志級(jí)別遇到空格切換到字段掃描STATE_FIELD讀取keyvalue對(duì)遇到空格繼續(xù)下一對(duì)遇到換行結(jié)束本行核心代碼示意大致長(zhǎng)這樣typedef enum { STATE_TIME, STATE_LEVEL, STATE_FIELD, STATE_DONE } ParseState; int parse_line(const char *line, size_t len, ParsedRecord *out) { ParseState state STATE_TIME; size_t i 0; Field cur {0}; while (i len state ! STATE_DONE) { char c line[i]; switch (state) { case STATE_TIME: if (c ) { state STATE_LEVEL; } break; case STATE_LEVEL: if (c ) { state STATE_FIELD; } break; case STATE_FIELD: if (c ) { cur.key_start field_start; } else if (c ) { commit_field(out, cur); state STATE_FIELD; field_start i 1; } else if (c \n) { commit_field(out, cur); state STATE_DONE; } break; default: break; } i; } return 0; }這段代碼是高度簡(jiǎn)化后的示意圖真實(shí)實(shí)現(xiàn)里我會(huì)把字段名解析和值截取分開(kāi)做還會(huì)處理轉(zhuǎn)義字符。但核心思想就是這個(gè)用狀態(tài)變量記住當(dāng)前在哪個(gè)階段每讀一個(gè)字符做一次判斷復(fù)雜度是O(n)理論上不會(huì)出現(xiàn)正則那樣回溯到指數(shù)級(jí)的情況。手寫(xiě)狀態(tài)機(jī)的另一個(gè)好處是我可以精確控制哪些字符需要處理哪些可以直接跳過(guò)。比如解析大量日志時(shí)很多字段我們是根本不關(guān)心的狀態(tài)機(jī)可以不把它們的內(nèi)容復(fù)制到任何緩沖區(qū)里直接跳過(guò)只保留字段起止位置后面需要時(shí)再按需拷貝。這種零拷貝思路比正則表達(dá)式那種“匹配結(jié)果即復(fù)制”的方式高效得多。3.3 內(nèi)存池和哈希表設(shè)計(jì)之前提到內(nèi)存池是本項(xiàng)目控制內(nèi)存的關(guān)鍵。這里的實(shí)現(xiàn)思路并不復(fù)雜我用一個(gè)鏈?zhǔn)降拇髩K結(jié)構(gòu)每個(gè)塊默認(rèn)64KB塊內(nèi)用offset分配內(nèi)存塊用完就新開(kāi)一個(gè)塊typedef struct PoolBlock { size_t used; size_t capacity; struct PoolBlock *next; char data[]; } PoolBlock; typedef struct { PoolBlock *head; size_t block_size; } Pool; void *pool_alloc(Pool *p, size_t size) { size (size 7) ~7; // 8字節(jié)對(duì)齊 PoolBlock *b p-head; if (b-used size b-capacity) { b create_block(p, max(p-block_size, size)); b-next p-head; p-head b; } void *ptr b-data b-used; b-used size; return ptr; }每次分配都從當(dāng)前塊的used游標(biāo)上切一塊出去不做單獨(dú)釋放。因?yàn)槿罩窘馕鰣?chǎng)景中所有需要保留到最終報(bào)告里的數(shù)據(jù)只包括聚合鍵和累加值這些數(shù)據(jù)一旦確定就不會(huì)再改變所以不需要在任務(wù)結(jié)束前釋放某個(gè)單獨(dú)的字符串。整池銷毀時(shí)只需要遍歷一次鏈表把每個(gè)塊free掉就行。哈希表方面我也沒(méi)有引入任何外部哈希庫(kù)而是自己實(shí)現(xiàn)了一個(gè)鏈地址法的哈希表。鍵是一個(gè)字符串視圖也就是指針加長(zhǎng)度而不是以\0結(jié)尾的字符串。這樣可以避免為了查詢?cè)趦?nèi)存池里額外復(fù)制一份同樣的字符串。哈希函數(shù)我選擇了FNV-1a這種哈希算法簡(jiǎn)單、速度快而且在處理短字符串時(shí)分布非常均勻。查找過(guò)程是先通過(guò)哈希定位到桶再在桶內(nèi)鏈表中逐個(gè)比較長(zhǎng)度和memcmp。因?yàn)檫@個(gè)場(chǎng)景的鍵通常比較短具體業(yè)務(wù)里一般也就幾十個(gè)不同字段桶里鏈表很短沖突基本可以忽略。但如果鍵數(shù)量非常多我會(huì)在初始化哈希表時(shí)設(shè)定較大的桶數(shù)比如默認(rèn)4096個(gè)桶在聚合數(shù)超過(guò)負(fù)載因子之后再動(dòng)態(tài)擴(kuò)容。內(nèi)存池和哈希表組合的精妙之處在于整個(gè)程序在生命周期內(nèi)不會(huì)調(diào)用很多次系統(tǒng)分配函數(shù)從而避免內(nèi)存碎片。我曾在處理10GB日志時(shí)觀察過(guò)RSS曲線它的峰值很穩(wěn)定基本是一個(gè)平臺(tái)狀態(tài)而不是那種鋸齒形波動(dòng)。3.4 參數(shù)解析與退出碼約定命令行參數(shù)解析部分是整個(gè)項(xiàng)目里最“無(wú)聊”的模塊但它直接決定了工具好不好用。caveman支持的參數(shù)不多這也是我刻意克制的結(jié)果caveman [-f input_file] [-o output_file] [--format csv|json] [--field TIME,CODE,COST] [--mode count|sum|avg]參數(shù)越少使用門(mén)檻越低也越不容易出錯(cuò)。每個(gè)參數(shù)我都選擇了簡(jiǎn)短且含義明確的命名而不是搞一堆縮寫(xiě)。同時(shí)我還支持從環(huán)境變量讀取默認(rèn)參數(shù)這樣在腳本里可以將一些固定配置收斂。退出碼的約定也必須固定下來(lái)。0表示正常處理完畢1表示參數(shù)解析錯(cuò)誤2表示輸入文件無(wú)法打開(kāi)3表示解析過(guò)程中出現(xiàn)了無(wú)法跳過(guò)的致命錯(cuò)誤。這個(gè)約定看著簡(jiǎn)單但自動(dòng)化腳本非常依賴它。比如在采集平臺(tái)里一旦某臺(tái)機(jī)器返回碼不是0調(diào)度器就能立刻知道任務(wù)失敗而不需要再去解析標(biāo)準(zhǔn)輸出里的錯(cuò)誤信息。標(biāo)準(zhǔn)輸出只輸出正式結(jié)果錯(cuò)誤信息全部走標(biāo)準(zhǔn)錯(cuò)誤輸出。這也是一個(gè)小細(xì)節(jié)但直接影響下游腳本能否安全地把結(jié)果重定向到文件。如果你在日志里混入報(bào)錯(cuò)信息那結(jié)果文件就會(huì)變成無(wú)法解析的垃圾。4. 常見(jiàn)問(wèn)題與排坑記錄4.1 靜態(tài)編譯之后竟然還是缺依賴?yán)碚撋霞恿?static之后生成的二進(jìn)制就不依賴任何動(dòng)態(tài)庫(kù)了但我在第一次部署時(shí)還是踩了坑拿到目標(biāo)機(jī)器上一跑提示Illegal instruction。排查了很久才發(fā)現(xiàn)問(wèn)題出在編譯時(shí)的CPU指令集。編譯caveman的機(jī)器是較新的CPUgcc默認(rèn)會(huì)根據(jù)當(dāng)前機(jī)器的特性啟用一部分新指令集擴(kuò)展而目標(biāo)服務(wù)器的CPU比較老不支持這些指令于是一執(zhí)行就非法指令。解決辦法是在Makefile里明確指定編譯目標(biāo)平臺(tái)的最小子集CFLAGS -marchx86-64 -mtunegeneric這樣編譯器只會(huì)使用所有x86-64處理器都支持的基礎(chǔ)指令兼容性一下就上去了。后續(xù)我在給其他架構(gòu)編譯的時(shí)候也會(huì)檢查-march參數(shù)比如針對(duì)ARM平臺(tái)會(huì)改用-marcharmv7-a或者直接不指定。這個(gè)坑提醒我靜態(tài)鏈接解決的是運(yùn)行庫(kù)依賴但解決不了CPU指令集差異。在面向多環(huán)境的通用工具上寧可犧牲一點(diǎn)本地機(jī)器的性能也要保證生成二進(jìn)制在目標(biāo)環(huán)境能跑。4.2 大文件處理時(shí)的內(nèi)存水位突然升高有一段時(shí)間我持續(xù)觀測(cè)到caveman處理大文件時(shí)的內(nèi)存峰值不穩(wěn)定有時(shí)300MB有時(shí)600MB。一開(kāi)始以為是哈希表擴(kuò)容導(dǎo)致但排查后發(fā)現(xiàn)真正的罪魁禍?zhǔn)资禽敵鰧?。原?lái)的輸出邏輯是在所有行解析完成之后把整個(gè)報(bào)告一次性拼成一個(gè)巨大的字符串然后再一次性write出去。這個(gè)字符串的大小取決于聚合結(jié)果數(shù)量而當(dāng)unique鍵數(shù)量很多時(shí)內(nèi)存自然飆升。解決方式非常直接改成分塊寫(xiě)入。每生成一批記錄就立刻調(diào)用write落盤(pán)并清空內(nèi)部緩沖區(qū)。因?yàn)閳?bào)告數(shù)據(jù)本身是順序遍歷哈希表產(chǎn)生的所以這不需要復(fù)雜的調(diào)度只需要在遍歷過(guò)程中維持一個(gè)小的寫(xiě)緩沖比如32KB寫(xiě)滿就flush一次。修改之后內(nèi)存峰值穩(wěn)定在180MB以內(nèi)即在處理10GB日志時(shí)也沒(méi)再出現(xiàn)過(guò)超出預(yù)期的情況。項(xiàng)目中凡是遇到內(nèi)存抖動(dòng)的大概率都是在某個(gè)地方攢了大量的中間數(shù)據(jù)而不是真正的業(yè)務(wù)數(shù)據(jù)量太大。4.3 管道模式下stdin的數(shù)據(jù)怎么處理另一個(gè)容易出問(wèn)題的是stdin輸入模式。如果用戶執(zhí)行cat file | caveman --format json程序是讀取標(biāo)準(zhǔn)輸入而不是直接從文件讀取。這本身沒(méi)問(wèn)題但我在初版實(shí)現(xiàn)里沿用了普通文件的lseek來(lái)跳過(guò)無(wú)效頭部結(jié)果stdin不允許lseek直接返回ESPIPE報(bào)錯(cuò)。這個(gè)問(wèn)題讓測(cè)試腳本時(shí)斷時(shí)續(xù)后來(lái)我統(tǒng)一用一個(gè)輸入抽象層來(lái)解決。這個(gè)抽象層內(nèi)部維護(hù)一個(gè)當(dāng)前讀取方式標(biāo)志普通文件模式下可以使用pread或lseek管道模式下只能順序讀取并維護(hù)自己的offset狀態(tài)。這個(gè)調(diào)整的影響面不小因?yàn)樗偈刮抑匦率崂砹恕拜斎朐础边@個(gè)概念?，F(xiàn)在caveman不僅能讀普通文件和stdin還能通過(guò)文件描述符參數(shù)與上游進(jìn)程協(xié)作處理一些更復(fù)雜的管道場(chǎng)景。4.4 在CI流水線里的集成思路既然部署場(chǎng)景是自動(dòng)化環(huán)境caveman自然也要能被CI流水線方便地使用。我在項(xiàng)目的tests目錄里寫(xiě)了一個(gè)run_tests.sh把常規(guī)使用場(chǎng)景全部覆蓋成斷言式測(cè)試#!/bin/bash set -euo pipefail caveman_bin${1:-./caveman} printf user1 code200\nuser2 code500\nuser1 code200\n | \ $caveman_bin --field user,code --mode count --format csv /tmp/t1.csv test $(cat /tmp/t1.csv) $user,code,count\n1,200,2\n2,500,1 echo PASS: basic count aggregation這些測(cè)試在每次代碼變更后都會(huì)跑所以后續(xù)迭代一直沒(méi)有鬧出過(guò)什么大回歸。CI流水線里我把編譯環(huán)節(jié)拆成了兩步先做常規(guī)編譯再跑一次針對(duì)老CPU的兼容性編譯。只有兩步都通過(guò)才會(huì)生成release二進(jìn)制。5. 實(shí)測(cè)數(shù)據(jù)與個(gè)人經(jīng)驗(yàn)5.1 測(cè)試環(huán)境測(cè)試這組數(shù)據(jù)使用的是一臺(tái)很普通的4核8GB內(nèi)存虛擬機(jī)磁盤(pán)是普通SSD操作系統(tǒng)是Debian 11內(nèi)核版本5.10。對(duì)比對(duì)象是團(tuán)隊(duì)原來(lái)使用的Python腳本它用正則表達(dá)式逐行匹配把所有結(jié)果保存在字典里最后一次性打印。輸入數(shù)據(jù)是一份模擬的訪問(wèn)日志共1000萬(wàn)行大小約1.2GB。字段包括時(shí)間戳、用戶ID、接口路徑、狀態(tài)碼和耗時(shí)。聚合任務(wù)要求按狀態(tài)碼和接口路徑兩個(gè)維度統(tǒng)計(jì)調(diào)用次數(shù)和平均耗時(shí)。5.2 性能與資源占用對(duì)比指標(biāo)Python腳本caveman處理耗時(shí)約23分40秒約42秒峰值內(nèi)存2.1GB156MB依賴需Python3.8無(wú)啟動(dòng)時(shí)間約0.45秒約3毫秒這個(gè)數(shù)據(jù)看起來(lái)差距非常大但實(shí)際測(cè)試并不意外。Python腳本在正則匹配和字典維護(hù)上有較大的開(kāi)銷而且它把中間結(jié)果全部保留到字典中又疊加了對(duì)象頭信息的內(nèi)存放大。caveman走的是流式處理和緊湊的內(nèi)存池存儲(chǔ)邏輯更貼近底層性能自然占優(yōu)。耗時(shí)從十幾分鐘變成幾十秒對(duì)于每天需要跑好幾次統(tǒng)計(jì)的任務(wù)來(lái)說(shuō)改善非常直觀。更重要的是內(nèi)存從2.1GB降到156MB這讓它能夠跑在一些配置很低的采集機(jī)器上不再會(huì)因?yàn)閮?nèi)存不足而被系統(tǒng)殺掉。5.3 哪些場(chǎng)景適合caveman從這半年多的使用經(jīng)驗(yàn)看caveman比較適合以下幾類場(chǎng)景第一是日志聚合。無(wú)論是Nginx訪問(wèn)日志、應(yīng)用日志還是業(yè)務(wù)埋點(diǎn)日志只要格式相對(duì)固定caveman就能用很小的代價(jià)完成統(tǒng)計(jì)。對(duì)格式不規(guī)則的文本它的狀態(tài)機(jī)設(shè)計(jì)也能通過(guò)新增狀態(tài)分支來(lái)適應(yīng)。第二是數(shù)據(jù)清洗和簡(jiǎn)單轉(zhuǎn)換。一些臨時(shí)性的文本處理任務(wù)如果把Python腳本部署到目標(biāo)機(jī)器環(huán)境實(shí)在太重。用caveman可以一次編譯到處運(yùn)行在處理大批量數(shù)據(jù)時(shí)還不容易卡死。第三是嵌入式或邊緣計(jì)算場(chǎng)景。那些機(jī)器資源非常緊張不僅是CPU和內(nèi)存連存儲(chǔ)空間都吝嗇。caveman一個(gè)300KB的二進(jìn)制放在任何地方都不會(huì)覺(jué)得占地方。不適用的場(chǎng)景也有。如果字段結(jié)構(gòu)高度動(dòng)態(tài)每行格式都不一樣那狀態(tài)機(jī)寫(xiě)起來(lái)會(huì)非常痛苦。這時(shí)候更通用的awk甚至Python反而是更好的選擇。另外如果需要實(shí)時(shí)監(jiān)聽(tīng)并處理持續(xù)到達(dá)的數(shù)據(jù)流caveman的單次運(yùn)行模型也不合適它更適合批處理。5.4 一些額外的經(jīng)驗(yàn)體會(huì)整個(gè)caveman項(xiàng)目做下來(lái)我最大的體會(huì)是工具的價(jià)值常常不體現(xiàn)在功能多少上而體現(xiàn)在它能不能在特定環(huán)境里穩(wěn)定完成一件事。很多時(shí)候我們并不缺功能強(qiáng)大的軟件缺的是能放在任何機(jī)器上、不用折騰依賴、不會(huì)半路崩潰的小工具。如果你也想做一個(gè)類似的工具我建議從需求清單開(kāi)始清晰寫(xiě)下你的邊界條件。這個(gè)清單會(huì)在你頭腦發(fā)熱想加功能時(shí)幫你保持理智。另外C語(yǔ)言項(xiàng)目的內(nèi)存管理一定不能圖省事散著malloc內(nèi)存池或預(yù)分配策略對(duì)長(zhǎng)時(shí)間運(yùn)行的批處理工具幾乎是必需品。最后一點(diǎn)多做真實(shí)數(shù)據(jù)的壓測(cè)。我用10GB日志壓測(cè)過(guò)caveman之后才發(fā)現(xiàn)自己最初的輸出緩沖設(shè)計(jì)有問(wèn)題。紙上推演一百遍都不如實(shí)際跑一次大文件來(lái)得直接。