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

想知道每天的这5G日志用来做什么

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

楼主本来的想法没有错，用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的吞吐量又是多大，两个一比较才知道行还是不行，差距又有多少。

极度同意楼上说法。。

现在做的一个项目需要每做一个操作就记下“日志”，以审核时供审核人查阅。这种其实是业务逻辑的一部分了，而不是传统的Log，所以一定是放在业务处理的事务中。

其实我觉得lz的需求可以有很多方法解决，主要是看你怎么设计的，如果让我来做，我会像下面这样设计。
1.既然log要和业务挂钩，要在同一个事务里面，那么我们可以为每一个业务分配一个id，所有记录这个业务的log都有同一个id。这样我们就知道每个业务有哪些log，也不怕不同的业务的log交叉写
2.为每个业务的log按照先后顺序分配一个index，这样我就知道他们的先后顺序，这样就不怕同一个事务的log写入次序不一样

按照上面的方法，我们的log可以自由的写入磁盘，不管你是什么方法，反正按照业务id和inde就知道这个业务的所有log

3. 每个业务的log开始都用一个专门的文字记录表示这个事务开始。
   在一个事务提交之前，用一行专门的文字表示事务准备提交。
  如果事务结束了，那么用另一个专门文字表示这个事务结束了。
  以后查log的时候，只有同时存在开始和结束我们才能肯定事务完整。

4.你的log记录器设计成自己的事务完整性，不要和你的业务挂钩，这样你可以用现成的具有事务完整性的log组件或服务器，log记录器单纯的接受业务系统的消息，只要有消息过来就接受，不管消息的内容，然后接下来的活就是log记录器自己的事，业务系统把log消息写过来之后就不管了，只要把log消息成功发到log记录器它就认为是成功。

按照上面的方法，所有的log日志都会记录，不管事务成功与否。

如果某个时刻你的业务崩溃了，那么通过log记录你知道这个事务到哪一步。
如果你的业务完成之后就崩溃了，但是没有发log日志发送到记录器，那么你必须通过“准备提交”log日志和实际的业务状态对比，知道这个事务是不是成功还是失败，如果是成功了，就补上log日志

也就是说你每天要有一个程序分析那些只记录到“准备提交”log的事务。

如果理解的没有错误，楼主的业务数据和业务log是两个数据库。

如果这样，写log数据库的，应该用jms。

大概如下，既能保证事务一致性，又能到达高效率的效果：

1) write local queue
2) transfered between local queue and remote queue
3) remote queue using MDB or others to write log database.

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

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

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

同意这种说法。

lz是不是想复杂了？为了日志的性能居然做成分布式，你觉得分布式就简单么？越复杂的东西就越不可靠。连JMS都上去了，到时候部署你这个通用日志组件就够管理员一茶壶了。

跨系统之间的事务，资源消耗越大，而且有的时候根本没有可能。

lz想复杂了，如果真需要lz说的那种日志，直接在业务事务中，把日志信息写道数据库里面完事了。

我们系统现在也对日志这块要求很高，我的理解这种情况下的日志已经是业务非常重要的一部分了，当成重要的业务功能来处理好了。
日志的统计，分析这块到目前为止感觉还不错