高并发下日志组件的各种实现方式

注明：此处所说的日志是指程序错误的日志。

一般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

• 拥有持久化机制
• 速度快
• 如果记录下的日志需要有查询功能，这个选择最好
• 不影响业务数据库性能

综上所述，也就是那句老话，看情况，然后自己看着办。