前言
這次編寫Node.js項目的時候用到了日志模塊,其中碰到了一個小問題。
這是一個定時執行可配置自動化任務的項目,所以輸出信息會不斷增加,也就意味著日志文件會隨時間不斷增大。如果對日志文件大小不加以控制,那么服務器的磁盤遲早會被撐滿。所以限制文件大小是有必要的。
最理想的控制方式就是當文件大小超過限制時,清除最先記錄的數據。類似一個FIFO的隊列。
# 刪除前面的數據- 1 xxx ...... 100 abc# 文件末尾追加數據+ 101 xxxx
log4js的file rolling
一提到記錄日志很多Node.js開發者肯定會找到log4js,先來看看log4js是怎么處理這個問題的。
log4js分為很多appenders(可以理解為記錄日志的媒介),file rolling功能可以通過函數來進行配置。
file rolling功能有兩種方式:日期和文件大小。
要控制文件大小,當然選擇后者。
為了測試這個功能是否滿足我們要求,寫一段循環代碼來寫日志。
const log4js = require('log4js')// 配置log4jslog4js.configure({ appenders: { everything: { type: 'file', filename: 'a.log', maxLogSize: 1000, backups: 0 }, }, categories: { default: { appenders: ['everything'], level: 'debug' } }});const log = log4js.getLogger();for (let i = 0; i < 41; i++) { const str = i.toString().padStart(6, '000000'); log.debug(str);}執行之后生成兩個文件a.log和a.log.1。
其中a.log.1有20行數據,實際大小1kb,a.log只有1行數據。
雖然確實控制了文件大小,但是會帶來兩個問題:
額外產生一個備份文件,總占用磁盤空間會超過文件限制。 日志文件內容的大小是變動的,查詢日志的時候很可能需要聯合備份文件進行查詢(比如上面的情況日志文件只有1行數據)。推測log4js的實現邏輯可能是下面這樣:
檢查日志文件是否達到限制大小,如果達到則刪除備份文件,否則繼續寫入日志文件。 重命名日志文件為備份文件。這顯然不能完全滿足需求。
字符串替換?
如果要在內存中完成循環覆寫操作就比較簡單了,使用字符串或Buffer的即可完成。
添加字符串/Buffer長度,如果超過大小則截取。 寫入并覆蓋日志文件。但是有一個很大的問題:占用內存。
比如限制文件大小為1GB,有10個日志文件同時寫入,那么至少占用10GB內存空間!
內存可是比磁盤空間更寶貴的,如此明顯的性能問題,顯然也不是最優解決方式。
file roll
按照需求可以把實現步驟拆成兩步:
追加最新的數據到文件末尾。(Node.js的fs模塊有相應函數) 刪除文件開頭超出限制部分。(Node.js沒有響應函數)新聞熱點
疑難解答
圖片精選