高並發下日志組件的各種實現方式

注明：此處所說的日志是指程序錯誤的日志。

一般B/S程序記錄日志的方式最多的方式是獲取到exception后直接append到一個文本文件，當然也有記錄到windows event log的。我們來討論下當高並發量下的解決辦法：

有很多解決方式，如下：

1. 直接記錄為txt/xml文件
2. Windows Event Log
3. 當前進程的本地隊列
4. MSMQ
5. 獨立進程中的WCF服務（進程間管道）
6. 獨立進程中的WCF服務（異步調用方式）
7. 數據庫
8. Sql server的Service Broker
9. MongoDB（或者類似的NoSQL數據庫）

其實大多數情況下使用文本文件或者eventlog就可以了，不過這不在本次討論范圍，去掉。

數據庫：

• 這種也是不能用在高並發下，因為出現異常時，也許是由於數據庫導致出現的異常
• 日志數據庫不能和業務數據庫合並在一起，否則會互相影響（高並發下）

Sql server的Service Broker

• 啥都好，既快速、又能利用sql server的事務日志，完整性
• 可惜，是建立在sql server這個大物之上的，所以不建議，理由同上

當前進程的本地隊列

• 從調用上講，是最最快速的，無與倫比
• 可惜，沒有簡單搞笑的持久化機制實現，要用，也可以，單次調用效率會降低

MSMQ

• 非進程內消息隊列，單次調用速度上，沒有進程內部本地隊列速度快
• 內建持久化機制，即便down機，信息也不會丟失
• 能簡單的通過啟動多個消費端程序來消費隊列元素，可擴展性強 

獨立進程中的WCF服務（進程間管道） 

• 持久化機制取決於WCF服務實現方式，需要自己實現
• 本地機器上的進程之間命名管道通信，比網絡通信快（如：MSMQ，service broker，數據庫）

獨立進程中的WCF服務（配合msmq的異步調用方式） 

• 由於是與msmq合作，因此持久化機制已經存在
• 可惜無法使用命名管道（由於msmq的介入）
• 存在網絡上的通信，速度降低

MongoDB

• 擁有持久化機制
• 速度快
• 如果記錄下的日志需要有查詢功能，這個選擇最好
• 不影響業務數據庫性能

綜上所述，也就是那句老話，看情況，然后自己看着辦。