log4js
多程序陷阱與避免
基於log4js 0.6.14版本
log4js總共三篇部落格
《log4js原理解析》
《log4js配置詳解》
《log4js多程序陷阱與避免》
在node
之中由於單個程序記憶體存在
1.4gb
的上限，因此在一些大型的系統中，通常使用
cluster
的方式來執行。在
cluster
環境，也就是多程序環境中，在使用
log4js
時其實有乙個陷阱，可能很多人都遇見過，讓人錯愕。
在單程序環境中大家會使用
file
或者datefile
型別的例項來寫日誌，並且為了日誌的自動清除還設定了滾動方式，按照檔案大小或者日期進行滾動。但是這兩種型別的
在達到滾動閾值時，先進性
rename
，然後建立乙個新的檔案，把後面的內容寫入到新的檔案中。
例如：在
datefile
按照天進行滾動的環境中，日誌檔名為
cheese.log
rename cheese.log cheese.log.2015-01-17
create file cheese.log
write cheese.log
在單程序環境中，這完全沒有問題，但是在多程序環境就會有問題。問題就出在每個程序都要執行上面的
rename
與create
操作。在多程序寫同乙個檔案時，實際上只要有乙個程序執行
rename
與create
操作就行了。
例如：
程序a先被觸發，執行換天備份日誌操作：rename cheese.log cheese.log.2015-01-17
create file cheese.log
write cheese.log
在後面的某個時間，程序b也被觸發了，再次執行換天備份日誌操作：
rename cheese.log cheese.log.2015-01-17
create file cheese.log
write cheese.log
看出來了吧，在被執行了第二次之後，
2015-01-16
上的資料其實丟失了，
cheese.log.2015-01-17
檔案內容只是程序
a備份到程序
b備份，這段時間的日誌。現在問題說清楚了，我們來想想解決方案。
問題的關鍵出在多個程序在不同時候執行了換天備份操作，那麼如果能夠保證只有乙個程序執行換天備份就沒問題了。 在
log4js
中提供了兩種這種型別的
，分別是
clustered
與multiprocess
，都是在
master
程序上開啟監聽，
worker
程序將日誌簡單地傳送給
master
，日誌的寫入備份等操作都有
master
程序進行。但是這種方式有乙個缺點，日誌通過網路傳輸，
node
是先緩衝到本地陣列，然後提供給
socket
緩衝區，假如網路寫入速度比日誌寫入速度慢，那麼以為著程序的記憶體占用會越來越多，最終可想而知了。
另外一種更好地方式是使用
datefile
型別的，但是設定
alwaysincludepattern
屬性為true
，也就是說每次寫日誌直接寫在
cheese.log.2015-01-17
這樣的檔案上，換天的時候寫到新的日誌檔案即可。這種方式就去掉了
rename
日誌的過程，從而避免多程序導致的日誌
rename
混亂。
關於clustered
、multiprocess
、datefile
型別的具體配置，請看另一篇部落格《
log4js
配置詳解》中
「datefile配置」
，「multiprocess配置」
，「cluster配置」
的三個小節。
log4js總共三篇部落格
《log4js原理解析》
《log4js配置詳解》
《log4js多程序陷阱與避免》
日誌管理 log4js
版本 安裝 npm install log4js封裝 log4js 在專案根目錄下新建檔案logger.js var log4js require log4js log4js.configure replaceconsole true 替換 console.log levels exports.lo...
Log4js原理解析
log4js原理解析 基於log4js 0.6.14版本 log4js總共三篇部落格 log4js原理解析 log4js配置詳解 log4js多程序陷阱與避免 一 概述 網路上有不少關於log4j的原始碼解析文章，但是到目前為止還未見到乙個log4js的原始碼解析，雖然這兩者有其共同之處，但是在實現...
node 日誌管理log4js
我們使用express框架時，開發模式用node或者supervisor啟動nodejs應用時，控制台都是顯示如下的日誌。get css bootstrap.min.css 3041ms get css my.css 3040ms get js bootstrap.min.js 3044ms get...