如何减少日志记录占用的系统资源

我现在要做的日志组件不同于传统的日志（Log4J、JDK Logging等），这些日志信息不是基于代码级的，而是基于业务级的，所以不存在“级别”（INFO之类）的问题，只要应用程序有需求，就要记录日志。现在问题就在于要保持事务一致的情况下如何降低对应用程序的影响，我曾经做过数据移植程序，发现数据持久化的瓶颈在于写入数据库的时刻，用JDBC向数据库写入一条数据是毫秒级的，如果一次写入1000条以上，对应用程序的影响就比较明显了。

个人认为是在扯淡。
你们公司是做应用的还是做产品的？
做应用有多少个项目？
做产品的有多少个产品？
有搞通用日志组件的必要么？
什么叫日志组件？日志组件都有哪些方面的功能性、非功能性要求？现有的日志解决方案都有哪些，哪些方面不能满足你们的要求？

做这个事情的初衷有没有想清楚，就讨论怎么做了。

为了日志的性能做成分布式还说可以减少应用服务器负担，我觉得lz就是在搞笑。

确实如兄台所说，目前我们项目也写类似的所谓日志，该日志应该是业务逻辑的一部分，实际中除了要记录成功日志，而且还要记录失败日志，因为往往出问题时候是失败的情况，系统管理员需要去查找原因，所以我们是在一个单独的事务中记录。

楼主本来的想法没有错，用JMS，异步来写日志
把日志都写到一个queue，然后另外一个机器或服务来监听这个queue，收下来后完成化，JMS也是有事务的嘛，所以完全可以保证事务性。

我不太清楚楼主所说的JMS Server答复时间是什么意思？你不会是要等完成日志持久化后再发一个JMS消息回来给应用吧！如果是这样的话说明你还没有理解JMS。如果不是这样，那我觉得向JMS Server发一条消息还是很快的呀，人家股票消息传递都用JMS，不知道你用的是哪一个JMS Server。此外，如果真是还是嫌慢的话，那就不要使用持久消息，这样速度会更快，只是如果JMS Server崩溃的话，那些还没有持久化的日志会丢失，不过，一般的JMS Server稳定性还是很高的，大不了再做一个HA

楼主自己的思路是对的，性能的问题最好先去实践一下，如果真有问题，要是我，也是在这个方案的前提下再去解决性能问题，因为从面临的问题来看，这是一个很正确的解决思路，其它方案的问题如下：
1、Cache 无法保证事务性
2、内存数据库  如果是纯内存数据库，一样没办法保证事务性，如果内存数据库本身也要持久化，那不见得比直接写日志快，可以把日志看成是一种特殊的数据库

所以楼主如果能接受JMS Server万一崩溃后的日志丢失，那就用这种方案，如果不行，就还是用持久消息，只是楼主说的慢到不可接受具体慢到什么程度？你们的应用高峰时一秒会产生多少笔日志？你测的JMS Server的吞吐量又是多大，两个一比较才知道行还是不行，差距又有多少。